State machine geting stuck: mov commands not triggering

[Saxony Thermal 0]

Hello, I really appreciate the help I have gotten from you all. Thank you so much.

I have an anomaly I need your experienced opinions on: When my state machine gets to state 3, it will hang and not update the state machine variable to go to the next state. I use [MOV K24 D3999] where it hangs; and is an example of how I do all my state changes which do work. (my states are 21 through 28; 8 states total).

Each state is super simple like this one attached where it hangs, I could easily simplify to a few states, but I did 8 for debugging and organization purposes. Maybe I can get around it if I shrink my state machine but but it shouldn't be hanging like this and I should learn what the issue is to help me out later with bigger state machines.
==================================================

About the attached image: D3999 is the state machine variable and it shows state 23 (the 3rd state) so this rung is active. It does a bit shift on something to the left as expected, increments a Z10 variable for some outside operation as expected, but fails to move 24-decimel into D3999 so it hangs here.

The image is snapshotted during live operation: the [= D3999 K23] is live, shown by its blue highlighted boarder. The bit shift and increment do happen, and if I did not make them P functions (P means pulse so they happen only once on a rising edge) then they operate repeatedly when it hangs making it stuck shifting millions of times and counting Z10 like crazy. But MOV and MOVP does not matter, it will NOT mov K24 into D3999.

The fact that the SFL(P) and INC(P) functions right next to the MOV(P) function do work, but MOV(P) will not, is really odd.

I can manually enter 24 into D3999 in the watch menu, which works, and the state machine continues on. Every other state uses the same logic (using MOV K# D3999) successfully and so the machine cycles back to this 3rd state (like normal) but then get stuck on this 3rd state.

Any ideas why it is doing this? I do not use SET or RST on D3999 to avoid that kind of latching...

Note: I tried INC(P) on D3999 here since it always goes from state 23 to state 24 (states 3 to 4), but the INC(P) also fails to increment D3999. INC(P) Z10 works though...??

 

 

 

Edited 29 May by Saxony Thermal

[Saxony Thermal 0]

Note: I know I do not need P for these functions because once entering the state for the first time, the state will always change on the next scan cycle so it will always happen once. I just made them P's so they were not cycling a bajillion times because it is getting stuck here for some reason.

But on that topic, is it more computationally efficient to specify P or not? If you happen to know. I am doing fine keeping cycle time down but was just thinking of other ways to shave down that time.

And if P is equivalent to non P, then I might P most of the time just to prevent bugs like these that can cause catastrophic changes to control variables. I'd rather it just bit shift once and hang.

Edited 29 May by Saxony Thermal

[Saxony Thermal 0]

Well I 'fixed' it but would enjoy any comments from those more knowledgeable because I don't understand the fix.

I noticed that parts of other states were operating even though it was showing state 3 constant. I noticed this by watching other variables in the watch window and was wondering why Z10 was incrimenting only up to 6. Well, like it is supposed to, when it is 7 then it resets to zero but this happens in state 7. Somehow, that reset was firing without its next rung firing as well to go to state 2. So it was resting Z10 and preventing transition to state 2 so it was looping states 3 through 7... but not wholesomely, more like piece-meal.

I fixed the bug by moving RST Z10 to state 2 (as it was inconsequential whether it was done in state 7 or 2) and this fixed my issue. Very odd. I will think about why that is.

I thought that maybe swapping the rung order to change the state variable to 22 first, then reset Z10 might have an equivalent fix, but that causes my hanging loop issue again. So RST Z10 must be in another state.

Attached is an image of state 7 (as K27 in my code), where I show the old RST Z10 location but turned off with SM401. It is instead in state 2 since it would get executed anyways along that path.

[Gambit 334]

It's going to be hard to find the bug in the program without the complete code. I'm sure the MOV K24 or INCP was works but another rung must have been active writing 23 back again.

But if you run into something like this you should use the Dataflow Analysis function. You are using GX works 3 right ?
(Right click on D3999 and select dataflow analysis)

If it would be a code compiling issue I would turn of the steps optimisation in the options menu.

Edited 30 May by Gambit

[Saxony Thermal 0]

Wow! Dataflow analysis is awesome. Thank you, I had no idea that could exist. And yes, this is GXworks3.

 

You remind me of C where the optimizer can harass my code if it misinterprets something as 'useless'. That certainly can happen here with all the extra steps I know I do not need to make in this state machine, but I make them for organizational purposes and easier debugging.

Unfortunately I can't reveal too much of this proprietary code, but you gave good ideas.

I did find that sometimes the scanning will not always fire a P (pulse) function each scan. I did a bigger state machine this morning and it hung on a sequence of INC(P) during a state. That state uses one INC(P) most times but there is an extra condition for a second INC(P), in which it hung. Changing them to INC stopped it from hanging. P was redundant in that case because at the end of the state it will always state change, so they will only always fire once. This is just interesting behavior to me.

Even if I do not know what the exact causes are, I know what the issue is and can work around them for now in acceptable ways.

 

Thanks for your help!