LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Lagging update in the probe window

 

Dear Community,

I am using LabVIEW 2017 and debugging a program where communication is performed over modbus. I run the program over long periods of time. Often when checking the probe values I notice that the time stamp inside the subvis is lagging in the probe window althought the vis containing them run through instantaneously (checking the ErrorIn and ErrorOut probes outside the vi).

What is wrong?

Thanks in advance for your feedback.

0 Kudos
Message 1 of 5
(364 Views)

@labviewette wrote:

 

Dear Community,

I am using LabVIEW 2017 and debugging a program where communication is performed over modbus. I run the program over long periods of time. Often when checking the probe values I notice that the time stamp inside the subvis is lagging in the probe window althought the vis containing them run through instantaneously (checking the ErrorIn and ErrorOut probes outside the vi).

What is wrong?

Thanks in advance for your feedback.


One thing that's wrong is that you didn't include any code for us to inspect.  Code = VI + subVIs.  Simplified version that still shows problem is A-OK.  A picture is usually not OK.  It's pretty much impossible to offer any meaningful feedback without being able to actually inspect the code, although some forum members have a Magic 8-Ball that works pretty well in some cases.

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 2 of 5
(359 Views)

I hope I haven't forgotten anything.

The subvi lagging is "Modbus ACK.vi", although the containg vi "MB Ethernet Slave_Main.vi" runs through smoothly without delays.

 

0 Kudos
Message 3 of 5
(324 Views)

Hi labviewette,

 

how much "lag" do you notice?

Which "values" do you probe?

 

On your "Modbus ACK" VI:

check.png

 

- Using a FOR loop running just once is RubeGoldberg.

- Comparing boolean values to boolean constants is always RubeGoldberg!

- The whole loop construct is RubeGoldberg as LabVIEW brings a function which does the same - see image…

- Those long strings of ModBus communication can be made "more clear" using a FOR loop iterating over arrays of ModBus registers and data values…

- You don't handle all possible errors in this VI…

Can you test your VIs again after doing those modifications?

Best regards,
GerdW
CLAD expired, using LV2011SP1 + LV2017 (+LV2019 sometimes) on Win7+cRIO
Kudos are welcome Smiley Wink

0 Kudos
Message 4 of 5
(321 Views)

 

Thank you for your effort GerdW,

yes you are definitly right. The code is RudeGoldberg (had to first lookup that word up!). Since I didn't have the time to improve the code I took over (it is not just this vi that needs cleaning up) I decided to measure the time the subvi needed to run and found that it runs through smoothly. So although I did not find out why the probes were lagging I was able to proceed with my work.

 

0 Kudos
Message 5 of 5
(290 Views)