01-15-2025 01:16 AM
Thankyou for the repnse, do you have any ideas or suggestions on how to ' close out' both of the read vi's , normally only one of the outs of the reads then goes to the close that is outside the loop, and idea on how to merge two of them to then have them go to the linx close ?
01-15-2025 03:21 AM - edited 01-15-2025 03:24 AM
@granty1988 wrote:
Thankyou for the repnse, do you have any ideas or suggestions on how to ' close out' both of the read vi's , normally only one of the outs of the reads then goes to the close that is outside the loop, and idea on how to merge two of them to then have them go to the linx close ?
You do NOT close out both. They are only one resource. You can't magically clone the serial port in your computer.
The Linx VIs under the hood are NOT multithreading safe in that they do not protect the communication channel with mutexes between the "write command" and the resulting "read response". So splitting of the resource wire into parallel wire strings to try to do things in parallel is a very bad idea. You could easily end up with the first Analog read getting the response from the second and vice versa or even more sinister mix-ups that render the communication channel messed up. So don't do that!
Even if you could do it because the underlaying communication VIs would use mutexes to protect the resource from concurrent accesses, you can only close one of the wires. The second and further attempt to close the others will produce an error as there is nothing to close anymore. And if you don't use a state machine or similar you could even end up closing the channel while one of the other VIs is still busy trying to read samples from the device.
Also trying to parallelize the communication by splitting of the wire wouldn't speed up your VI in any way if the underlaying communication was properly protected with mutexes, since the mutex will force execution into sequential execution anyhow. Since it is not protected, parallel communication can't work as it messes up the communication data stream.
Last but not least, trying to call those VIs in parallel, independent of the above reasons that make it a no-no already, can not and never will fix your instability problem. That must be something else.
01-15-2025 03:29 AM
Ok , that's understood , I was trying to figure out a way of getting more stable temperature reading, as the program that does work, has the analogue read in series of each other, and the temperature was second.
Could it be better if it's being read first then the ldr?
Or is there something else I could try ?
01-15-2025 03:37 AM - edited 01-15-2025 03:41 AM
So there is a program that works and one that doesn't. And the one that works has the analog reads in sequence behind each other?
Why did you even try to parallelize the two analog reads if you have a working solution already?
From the symptoms it would seem very likely that the problem is on the Arduino. Those analog inputs might be multiplexed and the input impedance of your signals is possibly to high to bring the according analog signal to a stable value before the analog converter tries to sample the value. Trying to fix that on the LabVIEW side is about as helpful than replacing your screen wipers when your car broke down.
01-15-2025 04:16 AM
Hello
Working , in the sense it runs, yes. However working in respect to a stable result , no.
When I ran it just on the Arduino and use the serial port via the idea, same setup and parts, just no LabVIEW, I did get a stable result
01-15-2025 04:28 AM
Well, they are not the same. In the LabVIEW Linx case you use the Linx VIs to read some analog channels through a very specific Linx shared library on the Arduino. In your serial IO solution you create an Arduino Ino code resource that runs on the Arduino and generates a serial stream that is then read in your terminal.
You can still run that Ino code and simply write a VI to read the serial port of your Arduino like the terminal does. You won't even need Linx for that, VISA alone is enough.