04-04-2002 05:07 PM
04-05-2002 05:07 PM
04-13-2009 06:57 PM
Hi all,
I'm currently trying to communicate with
the RTE-11 using LV 7.0. I downloaded the driver for the RTE-140
series, and I checked the guides for both series and found that they're
practically identical. I ran the driver, but got the timeout
error. I wanted to check the settings in the device, but had
trouble doing so as the process seemed different from the
manual's. Has anyone tried entering into the set loop of the
device? Any help would be greatly appreciated. The device
communicates through RS-232.
04-13-2009 07:29 PM
never mind,
I fixed the problem. Thanks
04-13-2009 09:04 PM
04-13-2009 11:24 PM
Hi all,
the driver for the RTE-140 workds for the RTE-111. Today, i got the chance to actually change the setting in the device and turned on the RS-232 setting and made sure that the baud rate, parity and stop bit matched. Although the reading vis from the driver worked, oddly enough I still couldn't write; I tracked down to the checksum vi where the array concatenation gave an "*" for the temperature bytes. I still haven't figured the problem; hopefully, I'll find out an answer tomorrow. Any help would be appreciated.
04-14-2009 05:07 PM
Hi all,
So, I still haven't figured out the problem with the checksum vi from the RTE-140 driver. It worked fine when concatenating a string of 5 or less bytes but anymore resulted in an "*". For instance, if CA 00 01 F0 02 01 2C is the input, it'd give a checksum of B (not the DF desired; checksum should be the addition of all bytes(starting 00)). I really appreciate it if someone can help. I've attached the checksum vi.
04-14-2009 09:10 PM
You have your Append Checksum boolean switch controlling a case selector. If it is set to True (Append Checksum), it takes two characters (1 byte) away from the checksum calculation and gives the correct result of DF. Since you loop through and begin with i+1 times 2, it begins with the 00 characters (1 byte) just like you want.
If you set it to false, it takes 4 characters away from the checksum calculation, thus the first two characters (OK) but also the last two (not good) and you wind up with the wrong checksum of B. Note you should probably set the width for the last number to hexadecimal string to be 2 so that you get 0B rather than just B.
Verify the integer representations you are using throughout the checksum. Many of your constants and wires are I16, but also U32 and I8. In reality, the calculation of the checksum should probably be just U8 throughout.
It would also be better if you set up your string array control to be in hex display and use the ASCII representions. Rather than having 2 characters represent a byte such as F0, it would be better if it was just a single byte that would show up as F0 if the control was in hex display. That way you don't have to do the 2 character manipulations all over the place.
Also, you can use the boolean functions such as XOR directly on a U8 integer numbers rather than converting them first to boolean arrays and back to numbers again. By handling the strings as ASCII bytes rather than 2character representations of a byte, and proper use of integer representations and boolean math, you could probably knock your code down to a third of what it is.
Attached is a VI with modified code (I can only save it back to LV 😎 along with a screen shot of the code.
04-15-2009 05:47 PM
Thanks so much Ravens Fan,
Not sure why, but I ran the same vi today on my laptop, using the same inputs, and strangly I got the desired checksum. In any case, you're right though; the vi can really be shorten.
thanks again
06-20-2011 04:36 PM
Thanks all for the information,
I downloaded the 2009 driver and am running into the same issues you all are.
Is it possible to replace the driver on line with one that contains these mods and works correctly?