05-19-2015 12:35 PM
Get rid of bytes at port. Read a large number of bytes. It will terminate automatically with the termination character as long as you configure the serial port to match the one you are getting. Then compare it to DONE\n (if your character is a line feed character, where that is shown in a string constant with \codes displayed. Actually you can probably just elimiante that entire inner while loop.
05-19-2015 12:46 PM
Thank you,
I can take care of that, now i only want to do that for the inner loop looking for "DONE", correct? And is that becuase i am instantly looking reading that i want to do it for that one?
05-19-2015 12:51 PM
You should get rid of all Bytes at Port all over the code and just use the termination character to know when to stop reading.
05-19-2015 12:56 PM
I can do that, but what if i am waiting for data over the port and there is no data, which can happen. I have no control over how the data is sent to the port, i can only listen and act based on the information that comes out, so if i have a visa read, the read will timeout. Is it better to have a timeout on the read than waiting for bytes at port?
05-19-2015 12:59 PM
You already have a timeout on the read. It is set at the Serial configure. Set it to a reasonable value. Default is 10,000 msec which I feel is generally too long. Try something smaller like 2000 msec.
Then you just need to do some error handling for when you do get a timeout error. Perhaps retry the command. Maybe have an indicator to flag to the user to check their cable.
05-19-2015 01:04 PM
The timeout will be frequent though. Some of the ports only have a couple lines of information coming over them every 5 minutes or so. But i can do that and see how that works. Do you see any reason for a freeze of the exe itself though? Could it be USB powerdown or possibly inproper memory management?
05-19-2015 01:47 PM
I didn't see anything about improper memory. That was my first thought too like continually opening a DAQ device or a serial port, but never closing. I didn't see any of that for as deep as I looked.
USB powerdown is a definite possibility.
As for other ports being less frequent, I wouldn't worry about that. As long at you have the query/response type of format, you should be fine. The timeout on the VISA read should be adequate to detect a response within a few seconds even if you don't query the device for minutes at a time.
A couple things I would modify, but don't think it would be the cause of a problem. Many places you have a reference constant wired to a property node. I would get rid of that reference and just right click the property node and use Link To to implicitly link it to a control. Second, there seem to be a lot of embedded loops and case structures down to several levels deep. I would lean towards a state machine architecture which should also help make the structures not have to be so deep.
05-19-2015 02:28 PM
I am not great with state machines yet, but next go around i will apply that. I will also impliment the timeout and the reference issues and hopefully that will fix the read issue i am having.
Thank you for all your help, much appreciated,
Matt
05-19-2015 04:25 PM
Ravensfan,
Do you have an example of the read timeout weve been talking about?
Thank you
05-19-2015 04:31 PM
Just look at the context help and/or detailed help for the Serial Configure VI.