LabVIEW
Error 1 occurred at Preview Queue Element Help
Solved!
Hello, I am using LabVIEW2020 and a VI in a much larger VI is experiencing the Error 1 (VI and error shown below). it seemed to come about when I was tidying up files in my project; moving all homemade Vis into a single folder. I updated the dependencies and even tried returning back to the old configuration, but I can't seem to stop this error from occurring.
Any suggestions would be much appreciated.
How did you "tidy things up"? If you used Windows Explorer to move things around, you might be okay if you put everything back AND have not saved the project file since the move. Always use the project explorer to move files around. That way the project knows where things are going and can update all the dependencies.
That being said, I guess your issue is that the queue ref is invalid. I have no idea why.
Hi narra,
@narra_1985 wrote:
It's dirty, but it so far seems to work...
Why do you think so?
Did you notice all those "ERR (-1)" notes in your image???
Question: What is the default behaviour of a function/VI when there is an error at its error cluster input?
You probably need to look in the caller that builds this cluster. ("release queue" in parallel somewhere? queue going through tunnels that use default if unwired, etc.)
Hard to say much from a picture, but the entire code shown seems a bit fragile, since the default timeout is -1, the timeout can never happen and the loop can never stop. Not sure what the purpose of the sequence structure is (how long does the subVI take?). What determines the loop rate?
@narra_1985 wrote:
Hi,
Do you mean moving files on the File tab of the Project Explorer? I think I may move files in Windows Explorer but then updated the file path. Is this bad?
I'm not sure why it would have caused the error shown though, it just seems to have coincided with this event.
Regards,
Arran
Moving from the file tab in the project explorer is how you should always do it. Moving them in Windows Explorer is never a good thing, even if you update the paths. The project does a lot more than just keep track of where the files are.
I really don't see how moving files around can keep the code runnable (unbroken), but giving new errors at runtime in the way you describe. I would think that any errors should show up way upstream in the caller. That's where I would investigate. Make sure your code is not discarding errors unseen. 😉
Do you see anything interesting if you also show warnings in the error list (ctrl+L)
@altenbach wrote:
I really don't see how moving files around can keep the code runnable (unbroken), but giving new errors at runtime in the way you describe. I would think that any errors should show up way upstream in the caller. That's where I would investigate. Make sure your code is not discarding errors unseen. 😉
Do you see anything interesting if you also show warnings in the error list (ctrl+L)
Oh, yes. My comments were tangential, at best, to this problem. I just mentioned it because they were doing something bad.
