LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bytes at Port Property Node. When to use it and when not?

Solved!
Go to solution

You should probably move the delay in-line so it is a bit more deterministic...

Frozen_0-1627654876872.png

 

---------------------------------------------
Former Certified LabVIEW Developer (CLD)
0 Kudos
Message 41 of 46
(1,658 Views)

@Frozen wrote:

You should probably move the delay in-line so it is a bit more deterministic...

Frozen_0-1627654876872.png

 


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.

0 Kudos
Message 42 of 46
(1,651 Views)

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. 

Rolf Kalbermatter
My Blog
0 Kudos
Message 43 of 46
(1,635 Views)

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.

 

 

 

0 Kudos
Message 44 of 46
(1,630 Views)

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!

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 45 of 46
(1,619 Views)

@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.

 

0 Kudos
Message 46 of 46
(1,565 Views)