Command requires GPIB Controller to be Controller in Charge on dequeue element

[Siniz]

I have some funky stuff going on in the attached VI. What the VI does is simply to log data to a text file. It is built up as a state machine. This VI's Create state is called from a mainVI (with the help of named queues). I get more than one error and it seems completely random.The error usually occurs if I stop the mainVI, then starts it again. So the second (or following) times the DP VI is called, I get random errors such as the two below:

Error 1 occurred at Dequeue Element in DP.vi->PSS.vi
Possible reason(s):
LabVIEW:  An input parameter is invalid.
---
NI-488:  Command requires GPIB Controller to be Controller in Charge.

Error 1 occurred at Close File in DP.vi->PSS.vi
Possible reason(s):
LabVIEW:  An input parameter is invalid.
---
NI-488:  Command requires GPIB Controller to be Controller in Charge.

Why is this? I don't even have a GPIB controller?

[johnsold]

I have not looked at your VI, but I can answer part of your question.  The error message can occur in two different circumstances.  One is the invalid input parameter and the second is the GPIB error.  If you do not have a GPIB device, then only the first definition applies.

My guess is that when you restart the system, some queue reference does not exist and this causes the error.

Lynn 

[Mark_Yedinak]

I suspect you are not cleaning up properly when you exit/stop your application. As stated in the Lynn's previous post you are probably getting an invalid reference to the queue. Your main application should create the initial queue as well as release the queue when you exit. Make sure that the queue has been created before starting your subtasks. Those can simply obtain the queue reference using the name.

Message Edited by Mark Yedinak on 10-20-2009 04:08 PM

[blawson]

Lynn is right - your error is the "invalid input parameter" error.

because some VISA (NI-488) errors have the same numbers as LabVIEW errors, labview shows them both.  This is both helpful (when you have NI-488 errors) and confusing (when you aren't using NI-488). Better to have too much info than not enough?

-Barrett "Controller in Charge" Lawson

[Siniz]

I do release the queue when I exit the program. If you look at the VI I attached, I sometimes get this error on the Write to Text File as well. The queue is a named queue that is created separately in the mainVI and DP VI. So I assume tthat it should not matter when I create my subtask. I am having a hard time seeing how this problem happens. Here is my mainVI (albeit messy right now) for your viewing pleasure.

[blawson · Accepted solution]

Are your shift registers uninitialized on purpose?

if you ever have an error in the dequeue element, the shift registers will be filled with  the error from the DQ and a blank file ref.  on the next call to this VI, if there is an error in the DQ, it will throw the invalid file ref on close error dialog. if there is not, the old error will propagate and you will get the dialog for it.

and I'll bet your DQ element is throwing an error because your enum in the DP QSM queue is a non-strict typedef and you've changed it somewhere.  make it strict!

I think there's something mixed up with your error case selector and the error case of your state machine.

Message Edited by blawson on 10-20-2009 04:47 PM

Message Edited by blawson on 10-20-2009 04:51 PM

[Siniz]

blawson, I think you found the error!

So shift registers only gets uninitialized again if I close the actual VI, and not when I start executing it again? So in reality, they actually behave like real shift registers? I found two solutions to this problem.

1) To initialize the error shift register with an empty error constant.

2) To remove the wire from the shift register to the Write to Text File. This works since I always call the Create state first.

Which one would you recommend?

Also, what is the reason to keep the typedef strict? I have seen non-strict in other code.

[blawson]

I went back and checked my assumptions on strict vs. non-strict type defs on enums and there's no difference between the two as far as which to use for a case selector enum.  sorry about that!

So you're trying to use the error out of the DQ element to signal that the queue has been released, right?  Well what's happened is that some other error snuck in and ate your cookies.  from the help file: "If queue becomes invalid (for example, the queue reference is released), the function stops waiting and returns error code 1122." so just test for error code 1122 in the error cluster and treat it like a dead queue if true, and handle it like you regularly handle errors if not.  The same thing is happening in both VIs.

-B

[Mark_Yedinak]

---

Siniz wrote:

blawson, I think you found the error!

So shift registers only gets uninitialized again if I close the actual VI, and not when I start executing it again? So in reality, they actually behave like real shift registers? I found two solutions to this problem.

1) To initialize the error shift register with an empty error constant.

2) To remove the wire from the shift register to the Write to Text File. This works since I always call the Create state first.

Which one would you recommend?

Also, what is the reason to keep the typedef strict? I have seen non-strict in other code.

---

Generally you should always explicitly initialize your shift registers unless you want to retain the values from one execution to the next. This is required for Action Engines but in most other cases you should use initialized shift registers to avoid side effects like you encountered in this application.

[Siniz]

Awesome guys, thanks!