Problems when communicating with multiple serial devices

[Gzimmer]

I have a VI (HHF11A.vi) which communicates via serial to my device. This works about 80% of the time, errors occaisionally with -1073807252 but repeated runs usually fix it.

I'm trying to incorporate this "driver" VI into a larger VI and as a test I tried running two devices at once in "2up.vi". This at best results in one device working, some times with the overflow error, but usually results in no reponses and no errors. Not sure what I'm doing wrong.

[diarmaede]

Hi,

I see a couple problems with your code.

1.  First and foremost, your subprogram runs a loop which only stops on an error.  This means that it will only pass output values to the parent program when an error occurs.  To fix this, you need to move your While Loop from your subprogram to your parent program, so your sub returns output values on each iteration.

2.  You are clearing, opening and closing your serial port on each loop iteration.  This will slow down your program considerably.  Unless you have a very good reason to write your code like this, I suggest that you clear and open your serial port, then go into your While Loop, then wait to close the serial port until your while loop stops.  Normally, I would open the port, then clear it, but I am not sure what the "official" sequence should be.

I hope this helps!

Cheers,

FB

[Gzimmer]

Alright thanks to you! I did manage to get two devices to work in the 2up.vi but I get the overrun error 0xBFFF006C with every iteration per device, which probably continues to cause the errors. How could I have the errors output their code without having the pop up pause my program if the error handling is in the subvi?

Also, if I would want to only close the VISA session when the loop is stopped, wouldn't I need to put that in the subvi, which seems to only work properly in the 2up.vi without a loop?

EDIT: I just tried turning the recieved buffer down really low, which works well for a few seconds before the overrun error issue pops up again.

[Dennis_Knutson]

Your code makes no sense to me. You are setting a fixed byte count to read. You would have no idea if the instrument is actually sending more bytes. You have termination character disabled but you are reading strings apparently. It is not normal for string data to be unterminated with something. Use a VISA Bytes at Serial Port to determine how many bytes to read. Run the VI once until there is data in the read buffer indicator, go to Edit>Make Current Values Default, save the VI, attach it.

p.s. It is silly to use a local variable in the subVI. Get rid of it. And if you don't want an error popup, don't use the simple error handler set to display a popup. Also, do as suggested and move the loop to the main VI, open and close there.

[Gzimmer]

EDIT: Just realize why you were so confused by the subvi, the 59 wired to the indicator is just an artifact from an earlier version where I had a control for how many to read and an indicator for how many are at the port.

From the manual for my device, the byte is sent in the form:

VXXX.XMPS:TXXX.XC:HXX.X%:dXXX.XC:wXXX.XV:vXXX.XCMM:UXXXXX.XKW

where X are obviously values. No termination character given.

If I were to split the string along every colon, it might make the code cleaner, but I'm simply sticking to how I've worked before.

The number of bytes I've set is from experimentation to only read what I need from the bytes sent.

Does the act of reading the bytes remove them from the buffer and therefore I should read everything at the buffer instead of cherry picking?

About the local variables, I've recieved this advice before from these forums. Is there a specific reason what I did is "silly"? Is the alternative to just have everything wired to the same block? I find it helps keep my programs easier to follow for me and modular.

[Dennis_Knutson]

Reading bytes removes them from the buffer. Bytes not read remain in the buffer and cause the overflow problem.

Your use of a local is a race condition. The data in the local could represent the latest or prior information from the VISA Read. You need to pay attention to the advice you have been given. There is a proper place for locals but this is not one of them. You need to use a wire. Locals are not at all 'modular'. They break dataflow which is the very basis of LabVIEW.

[Gzimmer]

Thank you for your patience Dennis.

I promise not to use local variables in this way again. With your explanation and additional research, I determined I have no idea when I would use them properly.

As requested, here is a typical run through of the driver VI. I haven't removed the close VISA block since I'm just fixing this VI first and then I'll reincorporate it into the larger VI. I actually would get zero bytes at the serial port on a single run through normally, but when I turned on highlight execution, this is what came out.

I went back over my old captured bytes, there is indeed a termination character, at the end of each line is a 0d:0a, so Carriage Return and New Line. My mistake and damn the omission in the manual.

[Dennis_Knutson]

Thanks for the real data. When you click on the read buffer string indicator, you will see a \r\n at the end. So, you can enable the termination character of the VISA Configure Serial port. The default of 0xA or a \r is fine. Then you can simply specify some high arbitrary byte count to read. The VISA Read will automatically terminate when the \n is detected. As long as the loop reads fast enough, it will keep up with the instrument and I hope the buffer over runs go away.

[Gzimmer]

Is there anything wrong with wiring the Bytes at Port property node to the Bytes to read? 

[Dennis_Knutson]

It's not a good idea when you have termination characters in the return string. The number of bytes could vary and you would get an incomplete string or one with too many characters. With the termination character, you might have to discard the very first string you read but after that, you are in sync with what the instrument is sending. You know you will get a complete data string with each read.