LINX

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView 2020

Highlighted

bbelley_0-1599779824621.pngbbelley_1-1599780068337.pngbbelley_2-1599780334764.pngbbelley_3-1599780461074.png

 

 

 

ERROR LOCATION?

bbelley_4-1599780779670.png

 

ERROR GONE FROM INCREASING TO 1000 MS.... NOT SURE IF THIS IS A PERMANENT FIX UNTIL WE DIG DEEPER INTO THE 'WHY' OF THE ERROR CAUSE....

 

bbelley_5-1599780899416.png

 

0 Kudos
Message 31 of 47
(279 Views)
Highlighted

ERROR LOCATION?

bbelley_4-1599780779670.png

 

ERROR GONE FROM INCREASING TO 1000 MS.... NOT SURE IF THIS IS A PERMANENT FIX UNTIL WE DIG DEEPER INTO THE 'WHY' OF THE ERROR CAUSE....

 

bbelley_5-1599780899416.png

0 Kudos
Message 32 of 47
(279 Views)
Highlighted

TEMP WORK AROUND... CHANGE THIS:

 

bbelley_0-1599781234481.png

'

 

TO THIS:

 

bbelley_1-1599781294503.png

BUT I DO NOT KNOW THE RAMIFICATIONS ON THE REST OF LINX.... IS SEND COMMAND VI ONLY USED IN ESTABLISHING INITIAL CONNECTION AND NOT FOR DATA TRANSMISSION?

 

I did a quick test where I made the constant 10000 ms instead of 1000 ms.... it appeared to delay completion of connection to mega by 10 seconds, but the loop rate held at 160 hz... whether I have a constant of 1000 ms or 10000 ms, whatever that means.... so could be a temp fix what I found?

Message 33 of 47
(274 Views)
Highlighted

Great work! I'm not sure the Synchronize VI is used anywhere else. It's basically sending an empty Linx packet to the remote side, which then has to respond with an empty sync packet. It's a simple way of checking that there is indeed something at the other side which understands the Linx protocol. So I think incresing the timeout in this VI should have no or very little side effects for the rest of Linx.

 

I wonder if increasing the number of retries would solve this too, probably not. How long does your connection establishment take with this? It shouldn't be more than about a second I would hope?

 

And now knowing the exact error location it does seem similar to another post I saw some time ago with a specific Arduino controller. Apparently some have a rather high initial response time when trying to establish a connection over serial.

 

In my (LabVIEW 2014 version of) Initialize Device.vi (the caller of the Synchronize.vi) I have before the call to the Synchronize.vi a call to the Packet Number.vi together with a delay node of 5000 milli seconds in a single cycle sequence frame. Do you have the same or did someone "improve" that to a lower value in 20202 to increase connection speed for the various remote targets? It seems one of the logical things that could cause this problem.

Rolf Kalbermatter
Averna BV
Message 34 of 47
(259 Views)
Highlighted

Good work guys. I am not that proficient in LabVeiw. Where do I locate the  Synchronize.vi to make the change please? 

0 Kudos
Message 35 of 47
(250 Views)
Highlighted

@rolfk wrote:

Great work! I'm not sure the Synchronize VI is used anywhere else. It's basically sending an empty Linx packet to the remote side, which then has to respond with an empty sync packet. It's a simple way of checking that there is indeed something at the other side which understands the Linx protocol. So I think incresing the timeout in this VI should have no or very little side effects for the rest of Linx.

 

I wonder if increasing the number of retries would solve this too, probably not. How long does your connection establishment take with this? It shouldn't be more than about a second I would hope?

 

And now knowing the exact error location it does seem similar to another post I saw some time ago with a specific Arduino controller. Apparently some have a rather high initial response time when trying to establish a connection over serial.

 

In my (LabVIEW 2014 version of) Initialize Device.vi (the caller of the Synchronize.vi) I have before the call to the Synchronize.vi a call to the Packet Number.vi together with a delay node of 5000 milli seconds in a single cycle sequence frame. Do you have the same or did someone "improve" that to a lower value in 20202 to increase connection speed for the various remote targets? It seems one of the logical things that could cause this problem.


Oh ok if you are saying that it used to be 5000 ms to connect before erroring out, then now it is at 100 ms... so way shorter..... looks like maybe they tested it on a device and it worked and they did not test all the devices... so maybe the arduino Mega Inability to connect is a deeper problem and more boards remain untested.... I have a teensy 4.1 board i could try.

0 Kudos
Message 36 of 47
(243 Views)
Highlighted

@Colinvellacott wrote:

Good work guys. I am not that proficient in LabVeiw. Where do I locate the  Synchronize.vi to make the change please? 


If you open up the Supporting sub vi  to the open connection vi and then keep opening up the next sub vi you can find it that way. I can put together better instructions once I get a chance.

0 Kudos
Message 37 of 47
(242 Views)
Highlighted

Thank you that would be good as I'm not sure which one  you mean by "supporting sub  vi"

0 Kudos
Message 38 of 47
(238 Views)
Highlighted

@bbelley wrote:


Oh ok if you are saying that it used to be 5000 ms to connect before erroring out, then now it is at 100 ms... so way shorter..... looks like maybe they tested it on a device and it worked and they did not test all the devices... so maybe the arduino Mega Inability to connect is a deeper problem and more boards remain untested.... I have a teensy 4.1 board i could try.


Not quite! I meant this here:

 

Linx-Initialize Device.png

 

This is the Linx::Initialize Device.vi. The circle indicates the delay of 5000 ms that I was talking about. The arrow points at the Linx::Synchronize.vi, which uses the default 100 ms timeout inside.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 39 of 47
(227 Views)
Highlighted

Sorry I am now confused can someone tell me please which vi I need to change and to what value.

 

My Initalize Device vi looks like this-

Colinvellacott_0-1599828862895.png

 

0 Kudos
Message 40 of 47
(225 Views)