LabVIEW
Bytes at Port Property Node. When to use it and when not?
Solved!
If you need hardcoded timeouts, it usually means you have an incomplete understanding of the communications protocol. I hate to say it, but hardcoded waits are needed only slightly more often than Bytes at Port.
Let's have a look at the documentation.
@billko wrote:
If you need hardcoded timeouts, it usually means you have an incomplete understanding of the communications protocol. I hate to say it, but hardcoded waits are needed only slightly more often than Bytes at Port.
Let's have a look at the documentation.
I would tend to agree with this. I was assuming that in this case the default timeout of 10 s was not being used.
@STTAndy wrote:
@billko wrote:
If you need hardcoded timeouts, it usually means you have an incomplete understanding of the communications protocol. I hate to say it, but hardcoded waits are needed only slightly more often than Bytes at Port.
Let's have a look at the documentation.
My intention is to write the command again immediately after recieving the data. It appears that if I write too quickly it does not respond hence the timeout waiting for data. I don't want to use queues or the data is not live.
Your probably right about not fully understanding. What I do understand is that it is time to go home 😁
I will look again tomorrow and see if I can learn a bit more.
Remember, the timeout only occurs if you do not receive the data. Just use a long timeout and write the next command as soon as the data is received.
@billko wrote:
If you need hardcoded timeouts, it usually means you have an incomplete understanding of the communications protocol. I hate to say it, but hardcoded waits are needed only slightly more often than Bytes at Port.
Let's have a look at the documentation.
As far as setting the timeout, only rarely should that be being changed after initialization. The only time I needed to adjust a timeout was when receiving a large packet of data (think multiple waveforms from an oscilloscope over a slow bus).
Hardcoded waits are needed for instruments that cannot process commands very quickly, which is quite rare, especially with modern equipment. I recently worked with an older power supply that had this issue. For this particular instrument, I was able to use the *OPC? query to figure out when the instrument completed the command and then move on. But I have also had to add 500ms waits for an oscilloscope to process a command or settings would be completely messed up (looking back, I wonder if the *OPC? would have worked on it). Ok, maybe I didn't make a good argument for hardcoded waits at all here. As always, it will depend on the device.
And documentation is the key to communicating with any device. If you don't know the protocol, you won't be able to talk to it. It would be like somebody speaking Spanish to me: I might pick up a word or two, but the rest will be gibberish to me.
I get the impression that some posts here use timeout and delays interchangeably. That is of course not true. A function with a timeout can cause a delay up to the specified timeout period but it can also return immediately. A delay will always wait the specified time which often can be much more than necessary but sometimes also is to short, causing all kinds of difficult to discern errors. A timeout error is a single clearly defined error and it is easy to treat it as a special case, meaning simply: There is not enough data to satisfy the current request! Don’t go to jail. Don’t feel abandoned! Just loop again and try reading again up to x times. If after x retries it still doesn’t give data, something else has happened (device crashed, cable disconnect, serial port went up in fire, or something similar). 😀
@crossrulz wrote:
@billko wrote:
If you need hardcoded timeouts, it usually means you have an incomplete understanding of the communications protocol. I hate to say it, but hardcoded waits are needed only slightly more often than Bytes at Port.
Let's have a look at the documentation.
As far as setting the timeout, only rarely should that be being changed after initialization. The only time I needed to adjust a timeout was when receiving a large packet of data (think multiple waveforms from an oscilloscope over a slow bus).
Hardcoded waits are needed for instruments that cannot process commands very quickly, which is quite rare, especially with modern equipment. I recently worked with an older power supply that had this issue. For this particular instrument, I was able to use the *OPC? query to figure out when the instrument completed the command and then move on. But I have also had to add 500ms waits for an oscilloscope to process a command or settings would be completely messed up (looking back, I wonder if the *OPC? would have worked on it). Ok, maybe I didn't make a good argument for hardcoded waits at all here. As always, it will depend on the device.
And documentation is the key to communicating with any device. If you don't know the protocol, you won't be able to talk to it. It would be like somebody speaking Spanish to me: I might pick up a word or two, but the rest will be gibberish to me.
I agree that there are specific cases when hardcoded waits are needed. Did I say "timeouts" up above??? Shame on me! I meant "hardcoded waits". Anyway, I once had a power supply that specifically said you needed to wait at least 12 ms (or something like that) for the command to process. That's why i want to look at the gory details - i.e., the manual.
If he was just sending commands, the it is possible he can't send them as fast as possible, but these appear to be queries, which should be safe to write immediately after read, but to make sure, I'd like to see the documentation.
@STTAndy wrote:
@billko wrote:
I agree that there are specific cases when hardcoded waits are needed. Did I say "timeouts" up above??? Shame on me! I meant "hardcoded waits". Anyway, I once had a power supply that specifically said you needed to wait at least 12 ms (or something like that) for the command to process. That's why i want to look at the gory details - i.e., the manual.
If he was just sending commands, the it is possible he can't send them as fast as possible, but these appear to be queries, which should be safe to write immediately after read, but to make sure, I'd like to see the documentation.
I agree but getting manuals for old Mitutoyo equipment is not easy, I think I have found its limitations now. If I write the next command too soon it does not repond, 190ms seems to be working great, 180ms and you get an occassional timeout. The best part is that I no longer rely on a delay between write and read, the only criteria is the delay before the write command.
I would like the speed to be better but the application I am working on will need to work with this old equipment because there is so much of it still being used in industry. My application is intended to upgrade some older systems without needing to replace all the hardware.
I have just taken 10,000 readings without a single hiccup so that is good. I already have code to find the serial settings of any new device that gets connected, now I think I need to improve that to find the optimum setting.
I ended up here in this topic because I have seen 'Never use 'bytes at port'' many times in this forum and I wanted to ditch it somehow so here we are.
It is working great now and hopefully it will continue to do so.
A-ha! Maybe I misread your post from before. A small wait in between a read and the next write are NOT unheard of. Maybe you have found the sweet spot.
@billko wrote:
@STTAndy wrote:
@billko wrote:
I agree that there are specific cases when hardcoded waits are needed. Did I say "timeouts" up above??? Shame on me! I meant "hardcoded waits". Anyway, I once had a power supply that specifically said you needed to wait at least 12 ms (or something like that) for the command to process. That's why i want to look at the gory details - i.e., the manual.
If he was just sending commands, the it is possible he can't send them as fast as possible, but these appear to be queries, which should be safe to write immediately after read, but to make sure, I'd like to see the documentation.
I agree but getting manuals for old Mitutoyo equipment is not easy, I think I have found its limitations now. If I write the next command too soon it does not repond, 190ms seems to be working great, 180ms and you get an occassional timeout. The best part is that I no longer rely on a delay between write and read, the only criteria is the delay before the write command.
I would like the speed to be better but the application I am working on will need to work with this old equipment because there is so much of it still being used in industry. My application is intended to upgrade some older systems without needing to replace all the hardware.
I have just taken 10,000 readings without a single hiccup so that is good. I already have code to find the serial settings of any new device that gets connected, now I think I need to improve that to find the optimum setting.
I ended up here in this topic because I have seen 'Never use 'bytes at port'' many times in this forum and I wanted to ditch it somehow so here we are.
It is working great now and hopefully it will continue to do so.
A-ha! Maybe I misread your post from before. A small wait in between a read and the next write are NOT unheard of. Maybe you have found the sweet spot.
Yes, this is very different from the timeout and sometimes necessary.
@crossrulz wrote:
As far as setting the timeout, only rarely should that be being changed after initialization. The only time I needed to adjust a timeout was when receiving a large packet of data (think multiple waveforms from an oscilloscope over a slow bus).
I totally agree. I generally even just use the default timeout, but might occasionally make it shorter if it is deemed necessary to know more quickly than 10 s if the communication has failed.
@rolfk wrote:
I get the impression that some posts here use timeout and delays interchangeably. That is of course not true. A function with a timeout can cause a delay up to the specified timeout period but it can also return immediately. A delay will always wait the specified time which often can be much more than necessary but sometimes also is to short, causing all kinds of difficult to discern errors. A timeout error is a single clearly defined error and it is easy to treat it as a special case, meaning simply: There is not enough data to satisfy the current request! Don’t go to jail. Don’t feel abandoned! Just loop again and try reading again up to x times. If after x retries it still doesn’t give data, something else has happened (device crashed, cable disconnect, serial port went up in fire, or something similar). 😀
I hope that I have not given that impression. My whole point was to use a timeout instead of a wait between the write and read as the timeout will result in only using the necessary amount of time to receive the data.
