07-30-2021 09:21 AM
You should probably move the delay in-line so it is a bit more deterministic...
07-30-2021 10:30 AM
@Frozen wrote:
You should probably move the delay in-line so it is a bit more deterministic...
I tend to agree with moving the wait inline, but it does depend a bit upon the requirements. With the parallel approach the total loop time is controlled, so the time from one command to the next is deterministic. By putting the wait time inline a smaller wait can be added and the time between read and the next write will be more deterministic. Assuming that there are significant variations in response times this should speed the overall operation while maintaining the necessary wait between read and the next write.
07-31-2021 06:58 AM
It would seem that the device in question is probably bitbanging the serial data over ordinary digital lines rather than using a dedicated, integrated UART circuitry. Considering that it seems to be an old (some remark in this thread) caliper type device (the only type of device I know from Mitutoyo) it’s quite possible. The CPU on such devices is often minimalistic and optimized for the measurement task at hand (and very low power consumption as they operate on a tiny battery) and anything else is more an afterthought than a design feature.
So the “serial port” may need time after bit-banging the data out before it is reprogrammed to be able to receive new data. In that case inlining the delay would be more logical as it gives the device a defined time to prime the serial port for receiving new data. If it is in parallel the potentially varying time for reading the response will impede with the necessary delay and you end up needing a longer loop delay to guarantee that the device is not overrun even if the reading of the previous response took longer than usual.
07-31-2021 10:02 AM
The caliper or similar uses I2C so mitutoyo produce various interface boxes, Mux boxes. I am using a very old one, modern variants may be faster. So, I write a command to the mux box, the mux box pulls a pin low on the device port and reads the data sent back from the device. It then transmits that same data out to rs232.
I have interfaced directly to mitutoyo devices using an arduino and got readings around 10ms apart (memory is not great so don't quote me). The delay is definitely in the mux box and the chain of connections.
07-31-2021 07:24 PM
I think you've probably taken it as far as it can go. You did a nice job migrating from Bytes at Port to just VISA read. Also, it seems that there's no way around a hardcoded wait in between the read and the next write, so you just went about trying to figure out how long it takes to "recover".
Overall, good marks for your effort!
08-03-2021 02:27 AM
@billko wrote:
I think you've probably taken it as far as it can go. You did a nice job migrating from Bytes at Port to just VISA read. Also, it seems that there's no way around a hardcoded wait in between the read and the next write, so you just went about trying to figure out how long it takes to "recover".
I think that sums it up nicely.