How to reduce loop iteration time?

[Rap_Master_T]

Hi all,

We're using the Occupancy Grid Map VI (i.e. OGM) in order to map a room with a robot and IMU. When we measured the duration of an iteration of the OGM, it was about a few hundred ms. After replacing the OGM IMU with ours (YEI instead of Microstrain) and adding a block for communicating with the robot (which updates the coordinates) the duration of an iteration is more then 10 seconds (12-15 seconds) which is really bad because the robot should map in real-time. The iteration of the robot's loop duration is 20-60 ms so we don't see why it adds such a delay to the OGM loop.

Can you please have a look at our code and maybe you can tell us why does an iteration take so long?

Thanks

[JÞB]

Well,

You forgot to attach the code.  Very often when loop time extend like that there is a timeout in a communications vi that is not getting handled correctly.

[Rap_Master_T]

Of course:)

Here's the code attached:

P.S. - How can I handle it correctly?

[JÞB]

OK You have a few problems with Tunnels and Shift Registers Look at the Tunnels I've circled here.  Every time the loop iterates they contain the exact same data

That means Image depth will have the same value (and there is a potential race condition where image info string may be read before it is written) so all of this code probably belongs outside the loop

The long delays you are seeing may very well  be VISA timeouts I modified the lower loop to demo a better practice of passing errors and IO sessions on SRs like so:

As you had it if an error occured you would never know because the loop would inteate and read no error from the loop input tunel

Now that "Polling" where you check those booleans every loop to decide what actions you want to take.  Its not very effecient.  Look at the Producer Consumer (Events) Design pattern template and search on Queued message handler.  That should point you in the right direction

[crossrulz]

That code it HUGE!  Which loop are you having problems with?  I would recommend turning some of that code into subVIs.  It will be a lot easier to read and also easier to narrow down the slow parts.

Serial communication in general is kind of slow.  But that's not likely your problem.

You could reduce a little processing with your converting to U32 by using the Join Number function (in the Numeric->Data Manipulation palette) or even simply with a Type Cast.

As I already said, break your code up into subVIs and look at each one to see if it could be a bottleneck.