action engine being accessed in an unknown part of my code

[PaulG.]

I've been at this LV thing for quite some time and I don't think I've ever been this stumped over something that could very well be a really stupid question on my part. But here goes ...

I have an action engine AE that I use to store and set setpoints and read status of a motor controller.

My bug: when my code is running in an idle state the action "write motor controller" should not be written to but is getting written to in some part of the code. I cannot seem to track down when and where this is being written.

Is there a way I can find out exactly when and in what vi a specific action in my AE is being written? I am using a heavily modified producer/consumer from the template. I have listed all the callers of this vi and everything is where it should be. I put a breakpoint on the "write motor controller" portion of the code and it gets constantly accessed while my code is idling but it shouldn't be since I'm only reading the data in the AE when I'm idling.

I'm really stumped.

[drjdpowell]

Put "Call Chain" attached to an indicator in your Action Engine; then you can see who is calling it.

[PaulG.]

---

@drjdpowell wrote:

Put "Call Chain" attached to an indicator in your Action Engine; then you can see who is calling it.

---

Tried that. It's what I would expect. It gives me the name of the AE then the main vi that calls it where it is called twice. Both are reads only. Nothing else.

[GerdW]

Hi Paul,

My bug: when my code is running in an idle state the action "write motor controller" should not be written to but is getting written to in some part of the code.

Just an idea: is the state input maybe unwired at some instance?

Could it be your AE was called with "write motor controller" before, but when you call it in your "idle" state the action input of the AE is unwired and reads the last action again?

[johnsold]

I have seen strange things happen only to find that the problem occurred in the state before the one where the symptoms appear. To diagnose it I created an FGV or AE which records changes of state on the state machine. I put a copy of the FGV in a separate VI which simply calls it in read mode about once per second and displays an array of recent states.

The sequence of states has been a useful clue for me several times.

I will look to see if I can find a copy of the FGV I have used in the past and post it.

Lynn

[johnsold]

Here is the FGV.  This is configured to use strings as state names but can easily be modified to use an enum if your state machine is set up that way.

Now that I have looked at this it does not require a calling VI. Just run a separate copy as a top level VI outside the VI you are troubleshooting. Whenever you want to look at the state history, click the run arrow with Reset = False and Rabbit Trail States empty.

Lynn

[PaulG.]

---

@GerdW wrote:

Just an idea: is the state input maybe unwired at some instance?

---

The AE function select terminal is required. I double checked anyways and all have inputs connected.

[Gregory]

Could you upload any part of the code, even just the AE? I'm on LV 2014

[Ben]

Hi Paul,

Put a break point (BP) in the action case that is being called from mystery land.

When the BP fires pull down on the drop-down where you usually go to set font. When a BP fires that control turns into a "call chain" inidcator and will tells you the call chain at the time the AE was invoked and the BP firied.

Ben

[PatrickLye]

When stumped like this I would consider adding in an additional array of strings to the FG. This array would only populate when the write state happens, and I would have a separate text at this input for every one of the instances of the FG. ex: spot 1, spot 2, spot 3, etc...

This should yield a pattern as to which instance of the FG is doing the unexpected write.

Another thing, if possible, would be to add a nop state to the FG, and where the FG is being written change the constant to the nop state to see if that leads in the direction you want. You could also turn each write on one at a time.