08-15-2013 03:20 PM
Hi,
So I have a producer loop which controls a consumer loop, however there is another consumer loop connected to the initial consumer loop! Sorry if this sounds confusing.
Basically upon exiting the queue in the initial consumer loop (which acts as a producer loop for the third consumer loop) I end up with the following error message : LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
I wonder why this is?
Abdulkarim
08-15-2013 03:25 PM
Can you upload the VI that is giving you problems?
08-15-2013 03:26 PM
Could you post a screen shot of the code?
08-15-2013 04:28 PM
Yes, code would be nice. Are all of your loops parallel? Does your loop three only run after loop 2 stops?
Are you using the same queue to pass data to the two consumer loops? You cannot dequeue in multiple loops from the same queue. Your results will be nondeterministic. The only time you may do this is if you are simply creating parallel processing loops which perform that exact same processing on the data and it doesn't matter the order they are processed.
08-15-2013 04:34 PM
I don't know if my screenshots will be of too much help - since my program is so large on screen. Regardless is there a simple way to do the following:
Have a producer and consumer loop and have the consumer loop be a producer loop to another consumer loop.
The reason I ask this is because my consumer loop iterates across a number of data acquisitions and needs to write the data to a file. If I incorporate the data writing feature within the loop it takes so much longer to run the machine and lags considerably - however when I place the writing file feature in another consumer loop it runs alot more faster and appears to write it fine till I exit the program and I get the error. I feel the error may have something to do with the program trying to coordinate between these three loops since there are so many queing/dequeings going on.
08-15-2013 04:38 PM
Screen shot 1 = end of the 2nd consumer loop
Screen shot 2 = second consumer loop (being fed by the 1st consumer loop)
Screen shot 3 = first consumer loop beginning
08-15-2013 04:40 PM
No, your pictures aren't very useful and they are also a sign of other issues. In general, your code should not be so big that you can't display it on a single screen. There are some minor exceptions but if your code is really big it is generally a sign of a poor design and code that is not very maintainable or reusable.It is very difficult to debug code when you have to constantly scroll around to see it. You pictures give no context as to what we are looking at. What part of your code is destroying the queue? At what point is the queue being destroyed? More often that not a simple picture of the code is not very useful and it is necessary to post the code, especially something that is not even viewable on a single screen. It's about the same as asking your doctor to diagnose you over the phone.
08-15-2013 04:50 PM
Hi,
Ok thanks for the honest and blunt advice! I understand that my code is a little unorganized at this point and that was pretty useless posting those screen shots.
However part of this is due to some premade code I had to work with. In terms of code readability when you say that it should only be viewable within a single screen - you don't mean simply converting large chucks into subvis right? I will probably begin working on coverting it to a readable form soon - I just wanted to wrap up the main function and then do all the cleaning up but perhaps it's better I prioritize the cleaning first so that it's much easier later on. 🙂
08-15-2013 05:04 PM
I believe the answer to your question lies in the picture "Queue Debugging 1.png". You are passing the Queue into a shift register, also both case structures that are visible in that shot are set to "Use default if unwired". I *believe* what is happening is that you are executing a state where the case structure leaves the queue tunnel unwired which causes it to go to the default value (not a refnum).
08-15-2013 05:07 PM
@Charles_CLA wrote:
I believe the answer to your question lies in the picture "Queue Debugging 1.png". You are passing the Queue into a shift register, also both case structures that are visible in that shot are set to "Use default if unwired". I *believe* what is happening is that you are executing a state where the case structure leaves the queue tunnel unwired which causes it to go to the default value (not a refnum).
- Use default if unwired is GENERALLY evil. Don't use it unless null values are actually desired, even then it isn't that hard to explicitly wire NaN/Null etc
- Queues are referenced based and therefore don't need to use a shift register at all
P.S. 1a. Use "Linked Input Tunnel"s instead of "Use Default If Unwired"