LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

device card

i got a question, what do you think is going on now, we didnt get no response at all from the device, do you think its a bad device card or something. this what make me think i dont know nothing about coding, this happen everytime when i cant get a device to work. but it never fails its never my fault, for the last two years it have always been a hardware issue  in my case. for some odd apparent reason im always getting the devices that dont work. then i got to keep changing my code 15 different ways doing the samething to make sure its not me.

 

but yeah we found the pattern out that the LSB  was the high bit. that was weird , we never seen that before. this is my second time using RS-232 so im learning alot. RS-232 must be an old standard cable or something.

 

 

So Al S what do you think the issue is now. when i do a ComRd , and i put the cursor over the bytes_read=ComRd(1,inbuff,7). the bytes_read saids it 0 ,which means its not reading nothing at all.

0 Kudos
Message 51 of 80
(2,013 Views)

I'm a little puzzled about your checksum calculation that is masking off 2 bits:

 

// calc check sum
outputdata[6] = outputdata[0] + outputdata[1] + outputdata[2] + outputdata[3] +outputdata[4]+ outputdata[5];
outputdata[6] = outputdata[6] & 0xFA

 

maybe it's only is a typing error, but I woud check your actual code since an incorrect checksum can give you some problems (nevertheless you should still get a 7-byte response message with an error code of 128 in the 4th byte).



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
0 Kudos
Message 52 of 80
(2,007 Views)

i comment out that line  earlier today, i think that need to be 0xFF.

 

or i dont really need that line anyway.

 

any thing else you think im missing in my code?

 

 

0 Kudos
Message 53 of 80
(2,004 Views)

No, nothing I can think of.

 

Have you checked your cabling by connecting to a second computer and reading the port?

Can you check your device with some test program by the vendor? Have you any or can aske them for it?



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
0 Kudos
Message 54 of 80
(2,002 Views)

yep they sent a program to me, im going to check it out tomorrow. but its in visual basic. do you understand visual basic, i dont know visual basic really,

 

if you could probably help interpret it in my code, im going to start doing that when i get to work tomorrow

0 Kudos
Message 55 of 80
(2,000 Views)

yep they sent a program to me, im going to check it out tomorrow. but its in visual basic. do you understand visual basic, i dont know visual basic really,

 

if you could probably help interpret it in my code, im going to start doing that when i get to work tomorrow

0 Kudos
Message 56 of 80
(2,001 Views)

I'm not so fond on VB, I don't even have it installed now on my machine, nevertheless after a quick glance at the code it seems to me that your application should work. Let's test the device with the vendor test program and see results.



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
0 Kudos
Message 57 of 80
(1,997 Views)
yea thats what im going to do tomorrow. if that dont work, it have to be the card itself
0 Kudos
Message 58 of 80
(1,995 Views)

Is the last code that you pasted the version you're actually trying to run?

There is a big chunk of code that is commented out:

From

    /*data <<= NUM_ADDRESS_BITS; // left shift data bits
...

To

        MessagePopup("%s","NOT READING ANYTHING, CHECK HARDWAREV!!");
       
    } */

 

Because of your memset() command, with this code commented out, you are sending data 0 and a DD card address of 0, which is not a valid DD card address (valid DD card addresses are 1 to 30). "An Address of 0 is reserved to indicate an End of File (EOF) condition for the SRAM profile."  I don't know if you'll get a response when your first command sends a DD card address of 0.

 

You know that your command code is a single character, so why declare it as an int for your MASTER_RESET_UPDATE_DEVICE function?  The compiler is automatically casting it as a char in your statement outputdata[1] = CommandCode;  I'd say just declare it as a char.

 

Have you tried sending a simpler command, like 'R' (Master Reset)?  The format of the command is simpler, and you don't have to worry about having the DD card configured correctly.

·         Format:                   [x] [R] [x] [x] [x] [x] [Sum of previous Bytes]

0 Kudos
Message 59 of 80
(1,962 Views)

Darnell:

 

You also asked earlier about whether it could be a cable problem.  Yes it could, but we couldn't give you any details about how the cable is supposed to be wired since there is nothing in the documentation you posted about the RS232 pinout.

 

 

RS232 defines two different types of devices: Data Terminal Equipment (DTE) and Data Communications Equipment (DCE).  Since RS232 uses separate Transmit and Receive pins, you need to know how your master card is defined.  PCs are DTE.  If the master card is also DTE, then you need a null-modem (or crossover) cable.  If the master card is DCE (less likely), then you need a straight-through (1 to 1) cable.

 

There is a bunch of info on RS232 cabling here: http://www.lammertbies.nl/comm/cable/RS-232.html

 

Are you using a cable that came with the card?

Do you have documentation on the master card RS232 connector pinout?

0 Kudos
Message 60 of 80
(1,962 Views)