06-19-2017 04:40 AM
Hello everybody,
I am working on my graduation project and I am developing a VI on LabVIEW 2015 that uses two VISA resources. Actually the main VI contains two other VIs, the first one communicates with a micro-controller via UART (serial port), the second one communicates with a machine via GPIB. Each VI works apart perfectly but when using both of them in the same main VI some problems appear with the first one. Actually sometimes the buffer misses a character or add a character or modifies a character which make my VI not reliable. I am sure that the data is sent properly from the µC (using a terminal or using the VI apart). I've respected data flow laws like connecting error wire and using sequence structure, I've inserted a delay in the loop (wait) and between the two VIs but the result is always the same and the problem always persist.
06-19-2017 07:58 AM
Need to see code. Preferably the code that works as well as the code that does not work.
06-19-2017 09:58 AM
Make sure each is running in parallel fashion rather than serially. Following the basic data flow guidelines in parallel processes requires some tweaking. Each process will still follow the basic data flow guidelines, it is the stitching of the processes that moves outside of the basics. Do NOT tie the error out of one loop/process into the error in of the other. While that maintains basic data flow, it does not allow for parallelism/independent processes.
06-20-2017 02:44 PM - edited 06-20-2017 02:49 PM
Thank you for responding me. I've attached a folder containing four VIs : Calibrated ATsensor is the main VI which use the two other VIs T-diode which communicates with the µc via UART and ThermalAir_LV_Command whic
PS : the VI called test GPIB is a simple VI that uses two VISA resources (serial and GPIB) that I've developed to locate the mistake but the problem is always there.
For the second response I've tried all combinations without any result.
06-20-2017 03:18 PM
I notice you're using the "VISA Configure Serial Port" VI, which sets up the serial port to use a termination character (\n, via default inputs that aren't wired up). Then you have "open" and "close" nodes, which I have observed that occasionally on some serial adapters/drivers can cause buffers to clear and on others the buffers remain intact, so it can be inconsistent. Then, despite having a termination character set up, you have a "Bytes" input field (appears to default to 27, which is oddly specific) that the Read VI uses.
I would suggest trying:
Remove the VISA Open/Close Nodess
Move the serial configuration outside so it only runs once per execution, not once per loop
Use either a termination character or an exact byte count, not both
Whenever you think all communication should be resolved, with no bytes remaining to send or receive, add in a VISA Clear node
06-20-2017 08:51 PM - edited 06-20-2017 08:53 PM
In your test GPIB.vi diagram, you send the literal string
TEMP1\s%f;GOTEMP1;DUTTEMP?\\r\\n\s
which is displayed here in \-code display.
Those termination characters are probably wrong. I'm going to suggest you might have instead preferred to end with CR,LF. The simple way to do this is simply change to \ display and remove the extra slashes. An alternative that makes the intention clear is to concatenate the CR, LF constants to the end, but I usually opt for the string constant like you have. I almost always use \ display when working with VISA strings.
Since your build_command_string.vi wasn't included, we can't check for sure, but if you have a similar string in the other VI, it might be something to avoid.