Error 91 occurred at Variant To Data in a QMH

[RepMat]

Hi

i am trying to build a toolkit for controlling a motor which used QMH. but i am having an error 91.

the main block diagram is as below

and the motor controller handling loop as below

even though i bundle some values to the typedef, the variant in the update display remain empty. I also tried to convert the data to variant before the enqueing, the variant remains empty message handling loop.

how to solve this error 91 problem?

would it be possible to trigger the 'update motor UI' of motor control handling loop to be triggered using a timed loop structure and it stops when the stop motor is triggered?

thanks in advance

[Yamaeda]

With the Disabled structure you cut the wire and send an empty Variant on ...

[RepMat]

Yamaeda 

i added some constants outside of disabled structure. still have the same issue

Error 1 occurred at Enqueue Element in Message Queue.lvlib:Enqueue Message (Single).vi->Motor control loop.vi->Main.vi

Possible reason(s):

LabVIEW: (Hex 0x1) 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 @.
=========================
Command requires GPIB Controller to be Controller-In-Charge.

[rolfk]

Most likely your MHL message queue refnum somehow got stale. Try to do a probe on it. Not sure if the probe window in your LabVIEW version shows more than the numeric value. If it doesn't, wire a "Is Not A Number/Path/Refnum" to that refnum wire and check its output.

How could a refnum be invalid?

- Maybe you forgot to initialize it? The code that does that might be disabled or not really called anywhere?

- Maybe you overwrite it somewhere with an invalid value?

- Maybe you do the initialization in a different execution context (top level VI) that has since gone idle? The lifetime of all LabVIEW refnums is tied to the lifetime of the Top Level VI in which the refnum was created. Once that VI goes idle (terminates execution) all refnums ever created in its hierarchy during its lifetime are automatically garbage collected! And yes I know some people object to call this garbage collection, but it is in the end still pretty much that, the only valid objection here could be that a refnum does not have to be garbage as it might still be used in a different execution context, but that are minor semantics in my opinion.

[Yamaeda]

[rolfk]

---

@Yamaeda wrote:

---

Could very well be! Although that variant going underneath the Enque nodes definitely is BUTT ugly. I'm not familiar with DQMH to know exactly if that wire actually goes to those nodes. Seeing them go under the terminal that connects with the actual Queue refnum, I possibly wrongly, assumed they just went underneath the nodes, not being connected. In either way wires going under nodes or not showing were they actually enter the node, are simply a grave violation of proper wiring.

[cordm]

That is a VISA refnum, not a variant. It should be wired through, but it is not the direct cause for the error.

Why do you stop the loop in update motor UI? That seems strange.

Something else must be enqueueing the empty variant, because it is not the shown case and the loop stops immediately afterwards.

Error 1 means the queue is invalid, which means something released it. Probably that VI after the case structure, because of the 91 error.

Why does the Update Display enqueue in Motor Main take three seconds to execute?