How can i make this VI run faster?

[coyotejr83]

I'm developing a project to repalce an old automation system from a food plant. The problem is that writing/reading from the PLC is becoming too slow, I'm using  arefresh rate of 1700 ms and even though some taskes like switching from an engine to other take up to 20 seconds. If I lower the refresh rate it takes even longer. What am i doing wrong? I'm attaching as well an CSV exported from the OPC Server (MX OPC 4.20 from Mitsubishi) because I'm not sure if the problem is on the OPC Server or on the VI.

Thanks everyone in advance

[Mark_Yedinak]

Rewrite the code. Seriously, your code is trying to do everything under the sun in one iteration of the loop. Something this large requires a better program architecture and should be split up into separate tasks. Your code would benefit from using state machines, a producer/consumer architecture (separate the UI stuff from the processing stuff), as well as some code cleanup. The code itself is fairly neat but when I need the side of a mountain to view the block diagram something is wrong. Generally you don't want your block diagram to be larger than a single screen. That does not mean smash everything together but refactor the code and use subVIs. As written everything inside the loop must complete before it can go to the next iteration. That means EVERYTHING. Even though there is parallel code within the loop everything in it will run at the rate of the slowest thing. The block diagram is so large it is difficult to say what that part is.

[Julio9]

Hi coyotejr83

Just like Mark said you should try using some design pattern as state machine, producer/consumer, master/slave, etc. This will simplify your code and make it more readable. Try following Mark's advices so you can identify wich part is making your 20 seconds delay, using subVI's and design pattern will make the each part of the code run just when it is necessary and not all the time like it just happening. Here ir a link  for information about a design patterns. 

Greetings

Julio 

[coyotejr83]

Obviously those words are hard to be listened and probably a little bit to be acomplished. My point is that I was believing that LabView wold only execute one While Loop at once. And as far as I can read on the architectures you guy showed me I can run multiple While Loops IF they are not one into another. Am I  right?

[Mark_Yedinak]

You can run loops within loops. Though if your code starts looking like this it is a sign you need to restructure things some. LabVIEW is a dataflow language and will executes things when all of its inputs are satisfied. The outputs of an object will not be available until everything inside it has completed. LabVIEW also allows for parallel execution. That is, if two things are both ready to run (all of their inputs are available) then both will run. The will run at the same time. If the input of one item it the output of another item the second item will not execute until the first completes.

With all this said your code has one HUGE while loop with everything inside it. That means as I explained earlier that a single iteration will require EVERYTHING inside the loop to complete before it can run the next iteration. This also means that the loop will run as fast as the slowest code inside the loop. The only way to make your code run faster is to separate out the various tasks you are running into separate tasks (think more loops) and run things in parallel. This doesn't mean everything will run at the fastest rate but it will mean that fast code can execute quickly and slow code will not impact the performance of the faster tasks.

Single huge block diagrams like your code are almost always slow and inefficient. In addition, they are very difficult to maintain and modify. Using proven architectures to structure your code will generally run very efficiently. Learn from all of the experience of those that came before you. A general guide line in LabVIEW is that a block diagram should never be larger than a single screen. If it is it generally means that the code is not modular and is difficult to understand. Think of reading a book. You wouldn't want to try and read a novel if the entire book was printed on one single piece of paper. Likewise you don't want to structure your code so that everything is in a single VI.

I apologize if what I said earlier was harsh but it was the reality of your code. Without some major rework it will be very difficult to get it to run any more efficiently.

[Julio9]

Hi coyotejr83

I apologisze too, I know that listen those words were difficult because you put your time and effort in it. I didn't mean to make you feel bad o something like that, there were just advices about your code, so it could be more efficient as you want, to make you code modular, scalable and maintanable. Again I'm sorry if I have been hard with my words. I hope you make changes in your code, and continue using LabVIEW, you are in a good way.

Greetings

Julio

[mikeporter]

The thing to remember is that LV is inherently parallel and uses dataflow to determine order of execution.

If you have two loop and one is not waiting for data from the other, they will both start executing in parallel. This is why you want to breakup large complex processes into multiple loops. That way faster processes can happen more quickly, and slower ones won't slow down the fast ones.

A couple recommendations: Before beginning the rework that you now see is needed, you need to learn about things like queues, notifiers and user-defined events. If you have multiple loops running in parallel you will need to be able to pass data between them, and these are some of the options that you have available.

Mike...

[Yamaeda]

Sub-vi's are your friend and will make it alot easier to identify what can be separate tasks. In several places i see 10 identical code parts, make a sub-vi(s). Also, even with sub-vi's you have e.g. 15 string using this same code copy, build an array (or place a constant) and loop through this sub-vi instead. Also, Index arrays can be expanded for the following items so you dont need 15 of them in one place. 

It's impossible to say what causes slowness without some better structure.

That said, as the other mentioned you'll probably end up with a some parallell loops for best performance.

Good luck.

/Y

[coyotejr83]

So, appreciating and folloing your advices, I've isolated this part of the code, which is the one that switches between motors when required by the OPC and writes results to the database. 

I'm having almost the same delay and can't find why, I hope than for the experts is now much easier to find the problem. I've tried with many cycle rates (2,000 to 100 ms) without good results.

Once again, everyone, I really apreciate your time and comments 

[Yamaeda]

Do you really need to do 4 database questions each loop, is the database that active? Or could you do it once outside the loop and use that result?

/Y