Stacked structure with sequence and for loops (signal generation)

[JAmuckro]

Hi there,

I recently stuck trying to implement my Matlab code in Labview for one DAQ project. The code itself is attached, but I will break it down so you can quickly point out where I made a mistake. Sorry that I didn't attach any decent screenshots, because I assume that there will be too many of them in one post.

global Torqueflag
global TorquePrev
global k
global NTOffset
 
TorqueMechS = GTorque*
TorquePhz = TorquePhase/4;
Tmax = 2500;
Torquemax = Tmax/0.65
ShaftOffset = 0;
NTOffset = 0;
WReached = 0;
LastCycleFlag=0;
ATororder = 0;
TorqueOrder = TorquePrev;
 Tlim = 0.8*Torquemax;
WLimit = Tlim*pi;     

This part of the code depicts initialization of some variables. I’ve decided to use a sequence structure with the initialization part in the first frame and then divided my code into two additional frames. For the variables, I was using local variables.

The cycle “If Trigger ==1” I’ve decided to omit, for now, just to make the code a little bit tidier. With regards to the second if cycle “if TorqueFlag==1” I used a case structure with a for loop where I put the equation for the TorqueOrder calculation and then the “break condition” cycle to exit the “if Torqueloop”.

After the cycle is finished and TorqueFlag = 0, the second part of the main loop starts executing – right now in the “False case structure”. All the if cycles are also there to check the system’s conditions and its parameters.

Overall it is a pretty simple code, but I think I made a mistake in the implementation of the n-count (Increment). The number of iterations should increase only in case of the “if TorqueFlag=1” when we are trying to reach the condition TorqueOrder<Tlim… So I implemented the outer loop as a while loop with shift registers, and it was working fine. I don't have my hardware system right now, so I was checking the code by inputting some constant values to the code, to verify its behavior.

However, I’ve noticed a bigger problem when I decided to test the code with the saved feedbacks from one of my simulations (the same code). So I have five save channels with the sample rate of 1ms. I input these signal to the designed code. I’ve never done, so after checking the forum, I found a really neat solution with the use of a for loop with the timing of 1ms that will mimic real generation of the signal. I’ve tried different combinations of for and while loops but could not make these two codes work together. I assume that either my iterations count has been implemented in the wrong way, or I need to do smth with all the for and while loops in the code. When I was troubleshooting the code, I’ve noticed that when the “k” reaches 17/18 cycles (it should be like this according to the math model), it resets to zero, and the whole cycle starts again. It causes some crazy oscillations in the output.

When I was checking the code on its own, I did not observe these issues. After counting the required number of cycles, the code switches to the “false case structure” and executes there.

I know that it is a long description of the problem and the code, but hopefully, it will help to save you some time. I have been trying to crack the code for the last few days and does not seem like I am getting any closer. Thank you and have a great day!

[StevenD]

Ugh, what a mess.

First thing, as the VI stands there is no reason to use any local variables. You only have one thread going on so just use the wires. LabVIEW is all about data flow and visually seeing what is going on. It's very hard to do that with local variables and they lead to race conditions (of which there are at least two).

Avoid sequence structures. Sequence structures are relics of a by gone age and upcoming versions of LabVIEW will not even have them. Again this comes down to data flow. If you use the wires you don't need the sequence structures, data will follow the wires from output to input. 

Clean up your block diagram. This code should fit on one screen but there are huge open spaces.

Organize your front panel. You have I think 7 charts and various controls and indicators scattered all over several pages of space. You have three front panel items with the exact same name, one chart, one indicator and one control.  

Not trying to be harsh, but readability matters. It's nearly impossible to tell what is going on when there is a local variable set somewhere attached to a wire that isn't used for two pages.

More to the core of your question:

When I was troubleshooting the code, I’ve noticed that when the “k” reaches 17/18 cycles (it should be like this according to the math model), it resets to zero, and the whole cycle starts again. It causes some crazy oscillations in the output.

k is equal to the "increment" local variable which is a signed 8 bit number (can have a value of -128 to 127). But it's a number that is incremented a couple hundred times (how ever many rows are in your csv file). When it hits 128 it will roll over to -128 so I don't think it's resetting to 0, it's going negative which seems like it's not intentional? 

I cleaned up the vi enough to try and figure out what is going on, I don't have the mathscript module so I had to convert some of those to basic LabVIEW native math functions, but other than that I think everything else should still be wired the same (just condensed). I'll attach that if you want to look it over. It's version LV2016 but I can save for previous if you need.

I've also taken a few screenshots of problem areas that still need to be fixed.

This is probably the reason you are seeing "crazy oscillations"

I8 will roll over from 127 to -128

Here are two race conditions in the VI. Which will happen first? No one knows.

-S

[StevenD]

Ugh, what a mess.

First thing, as the VI stands there is no reason to use any local variables. You only have one thread going on so just use the wires. LabVIEW is all about data flow and visually seeing what is going on. It's very hard to do that with local variables and they lead to race conditions (of which there are at least two).

Avoid sequence structures. Sequence structures are relics of a by gone age and upcoming versions of LabVIEW will not even have them. Again this comes down to data flow. If you use the wires you don't need the sequence structures, data will follow the wires from output to input. 

Clean up your block diagram. This code should fit on one screen but there are huge open spaces.

Organize your front panel. You have I think 7 charts and various controls and indicators scattered all over several pages of space. You have three front panel items with the exact same name, one chart, one indicator and one control.  

Not trying to be harsh, but readability matters. It's nearly impossible to tell what is going on when there is a local variable set somewhere attached to a wire that isn't used for two pages.

More to the core of your question:

When I was troubleshooting the code, I’ve noticed that when the “k” reaches 17/18 cycles (it should be like this according to the math model), it resets to zero, and the whole cycle starts again. It causes some crazy oscillations in the output.

k is equal to the "increment" local variable which is a signed 8 bit number (can have a value of -128 to 127). But it's a number that is incremented a couple hundred times (how ever many rows are in your csv file). When it hits 128 it will roll over to -128 so I don't think it's resetting to 0, it's going negative which seems like it's not intentional? 

I cleaned up the vi enough to try and figure out what is going on, I don't have the mathscript module so I had to convert some of those to basic LabVIEW native math functions, but other than that I think everything else should still be wired the same (just condensed). I'll attach that if you want to look it over. It's version LV2016 but I can save for previous if you need.

I've also taken a few screenshots of problem areas that still need to be fixed.

This is probably the reason you are seeing "crazy oscillations"

I8 will roll over from 127 to -128

Here are two race conditions in the VI. Which will happen first? No one knows.

-S

[StevenD]

Could not attach the VI to last post for some reason. Here it is.

[GerdW]

Hi Steven,

please replace ALL local variables by wires and shift registers. ALL of them!

And do you really need a MathScript node just to initialize some "variables"???

The other MathScript nodes just cointain some simple formulas, you should replace them with "plain" LabVIEW code too…

After all that: use AutoCleanup (again).

Edit: The above is valid for your "version 2" VI.

For "version 3" you already got rid of the MathScript nodes, but still have to replace all those local variables by wires and shift registers!

General hint: THINK DATAFLOW!

Edit2: Just missed the fact there are two different persons for message #1 and #2. Sorry for that…

[StevenD]

I don't know why my post keeps disappearing. I'll try this for the third time now.

First thing, as the VI stands there is no reason to use any local variables. You only have one thread going on so just use the wires. LabVIEW is all about data flow and visually seeing what is going on. It's very hard to do that with local variables and they lead to race conditions (of which there are at least two).

Avoid sequence structures. Sequence structures are relics of a by gone age and upcoming versions of LabVIEW will not even have them. Again this comes down to data flow. If you use the wires you don't need the sequence structures, data will follow the wires from output to input.

Clean up your block diagram. This code should fit on one screen but there are huge open spaces.

Organize your front panel. You have I think 7 charts and various controls and indicators scattered all over several pages of space. You have three front panel items with the exact same name, one chart, one indicator and one control.

Not trying to be harsh, but readability matters. It's nearly impossible to tell what is going on when there is a local variable set somewhere attached to a wire that isn't used for two pages.

More to the core of your question:

When I was troubleshooting the code, I’ve noticed that when the “k” reaches 17/18 cycles (it should be like this according to the math model), it resets to zero, and the whole cycle starts again. It causes some crazy oscillations in the output.

k is equal to the "increment" local variable which is a signed 8 bit number (can have a value of -128 to 127). But it's a number that is incremented a couple hundred times (how ever many rows are in your csv file). When it hits 128 it will roll over to -128 so I don't think it's resetting to 0, it's going negative which seems like it's not intentional?

I cleaned up the vi enough to try and figure out what is going on, I don't have the mathscript module so I had to convert some of those to basic LabVIEW native math functions, but other than that I think everything else should still be wired the same (just condensed). I'll attach that if you want to look it over. It's version LV2016 but I can save for previous if you need.

I've also taken a few screenshots of problem areas that still need to be fixed.

This is probably the reason you are seeing "crazy oscillations"

 

I8 will roll over from 127 to -128

Here are two race conditions in the VI. Which will happen first? No one knows.

 

-S

[JAmuckro]

Hi Steven and GerdW

Thank you for your comments. I deleted the sequence structure and most of the local variables. Left some only in the case structure. I've checked them and looks like none of them will cause race conditions. For the depicted part of the code (by Steven), I've used wires to pass the values, so they will be executed sequentially. Plus a couple of other improvements. By and large, I am getting k=18, which is the number of cycles that I should get. That's all good, thanks a lot. However I have one question more.

The input signal has the timing of 3s, which gives us 3000samples at 1ms rate. And it can be seen of the plots for the DriveS, DriveP and so on, However k (or Increment) returns the value of 4 and stops there. But technically since we have 3000samples from the spreadsheet in the loop, all the variables should be executed until their sample count will reach 3000. Maybe a little bit wobbly but you can see from the picture, where the TorquePhase had almost 2000 samples more, but k does not move anymore (time wise).

However it should reach 18 and stay there for the duration of the input signal. I was trying to solve by putting (all possible options) timing block to the case structure and the for loop there, but it did not change anything.  Could you please help me understand why does it behave like this?

And probably one more question for GerdW, since Steven does not use the mathscript toolkit. 

Don't remember the reason why I did not implement everything in one Mathscript node (since I have the matlab code), but I did it now. Works beautifully, exactly like in Matlab. Plus I've double checked myself with the cycles number, etc. I need this code to be executed at 1ms, and I was checking it in a timed loop. No signs of exceeding this sample rate. So I was just wondering, am I missing smth by using this option, instead of the rev.3 of the code based only on the standard labview blocks and structures? Will be great to hear some tips about it, or maybe some best practice.Thank you in advance for any tips...

P.S. Sorry that I can't post the updated code, the forum (or my browser) is acting up...

[GerdW]

Hi JAmuckro,

Could you please help me understand why does it behave like this?

As soon as you attach your VI again. Have you tried to ZIP it - or tried a different browser?

some best practice.

Well, usually "plain" LabVIEW is easier to read - and faster to execute…

[wiebe@CARYA]

---

@StevenD wrote:

I don't know why my post keeps disappearing. I'll try this for the third time now.

---

It's there 3 times now! Was wondering why you posted it twice...

[JAmuckro]

Oh finally,

Sorry guys, the code is attached. I've changed the equations, so the number of cycles (k) will be different. But the timing behaviour will show my issues. Thank you for your help!

GerdW,

Thank you for your response. That were my thoughts as well. Personally, can't think about a better (more plain) option than the whole code in a Mathscript node... However, I still want to understand what's going on with the timing during the code's execution. Thank you in advance.