Simple FIle I/O in a Queue throttled loop

[TG]

A free beer to the best answer

I have trouble with writing (appending) to text file in a QSM that is in an "occurence mode" of operation whereby the queue waits for outside engueue to go ahead and do a task. The task is simply to write to a file a line of text. (see above)

This circuit is contained within a Queues state machine loop. The loop keeps the file reference between iterations. Only an outside event triggers the loop iteration. (not shown)

Outside producers give the queue its go ahead and data is sent along etc...

WHat I am seeing in the logging function shown here (this is a subVI ) are multiple errors (Error 1)
Somehow Labview is not noticing that the reference is valid or it is invalidating the reference., hence the (silly) work around just to get something
positive going. Ive seen this kind of thing before my calling VI (outter loop) is not idle this time.


Q is Should I just let the outter QSM loop to keep it alive and would that work?

What is the rule concerning a loop controlled by queue waiting for an event? Does the VI get flagged as idle and is that why the ref appears to be dropped or is it more likely a cache issue? All i know for sure is is the recycled ref is closing OR generating Error1 just for fun..

The example above works when wrapped in a simple loop but not in my QSM loop that is waiting on an occurence.
Anyone know why?



Thank You

[Mads]

I do not think the reference is closed automagically, there must be some bug somewhere that closes or looses the reference.

Is it able to write once and then never again, or?

Does the file exist? The shown code never creates it (open, not open or create as action into the open/create/replace file function)...If it is a preexisting file, have you tried generating a new one?

If you feed the que twice and probe the reference and error outputs in this logging VI, does the reference ever change and where is the first error?

Mads

[orko]

QUOTE(TG @ Dec 3 2007, 08:06 PM)

This circuit is contained within a Queues state machine loop. The loop keeps the file reference between iterations.

Herin lies the problem. The loop is not keeping the file reference between iterations. You just don't know yet where it is being lost

Probe your file reference on the inside of your QSM, and put a breakpoint at the probe. You should be able to step through each iteration and see which one the file reference is going away at.

Without seeing your QSM code, it is just guessing on my part, but my guess is an unwired shift register in one of your cases (timeout case? default case?) on the wire that holds the fileref. Let us know what you find.

[TG]

QUOTE(orko @ Dec 4 2007, 07:19 PM)

Herin lies the problem. The loop is not keeping the file reference between iterations. You just don't know yet where it is being lost

Thanks orko, I appreciate the thoughts anyway. Ill try to get more info about this.

I have to wait until I can access the rig again for further development (troubleshooting) next week.

Yeah I am using a number of reentrant clone VIs. They are the producer points for the command to

go ahead and execute the diagram above which is a frame of a QSM very much like this one.

http://expressionflow.com/2007/10/01/labvi...e-architecture/

The QSM wrapped around this (example) code segment above however is static.

I probed the ref num and it is just a number so there is no way to tell if it is valid since sometimes it works and sometimes it shows an error

when asking it for the current file position.

I have seen this kind of thing before (and felt stupid before) where during a probe the ref appears to be valid but it actually is not, especially with Queue refs, DAQ refs etc..

[Kevin P]

What part of the code actually opens the file ref? I've been bitten before when I had a dynamically called process launcher vi that opened a bunch of refs to files and queues, etc. I then passed the refnums along to other dynamic code.

Trouble was, the vi that originally opened the refnums ran to completion and went into idle state. Shortly after that, LabVIEW closed all the refnums it had opened as part of its automatic garbage collection, and all my dynamic vi's started throwing errors.

Since it isn't clear to me where your file refnum gets opened, I wonder if you may have a situation like mine? (Assuming you've ruled out the earlier suggestion about one of the state machine cases failing to pass the refnum through to the right-hand shift register.

-Kevin P.

[TG]

QUOTE(Kevin P @ Dec 5 2007, 01:45 PM)

What part of the code actually opens the file ref? I've been bitten before when I had a dynamically called process launcher vi that opened a bunch of refs to files and queues, etc. I then passed the refnums along to other dynamic code.

Trouble was, the vi that originally opened the refnums ran to completion and went into idle state. Shortly after that, LabVIEW closed all the refnums it had opened as part of its automatic garbage collection, and all my dynamic vi's started throwing errors.

Since it isn't clear to me where your file refnum gets opened, I wonder if you may have a situation like mine? (Assuming you've ruled out the earlier suggestion about one of the state machine cases failing to pass the refnum through to the right-hand shift register.

-Kevin P.

Intersting Kevin..

Thats the thing. None of my vis are running to completion. Also there is no way to reduce to an example this since many VIs are instruments

and its all coupled.

I can't get access to the rig for another week so I'll speculate here, maybe someone can remember some rule or similar occurance.

The outter wrapper to the segment above is simply a queued state machine and it is dynamically launched (no wait until finished) from the MAIN processor state machine, which itself is static and runs continously.

In other words

MAIN is STATIC and launches PROCESSOR and LOGGER

PROCESSOR then launches various PROCESS's (clones)

the clones send data to LOGGER during their lifetime however the clones have no link to (or even awareness of) the file ref. Only LOGGER has the file ref in its memory shift register.

None of the important stuff is shutting down. its just that they are seperate entities not tied to each other by data flow.

The file ref seen above is opened by LOGGER

The segment above is contained within the "log to disk" frame of LOGGER..

Its all pretty simple actually, despite my imperfect attempt to illustrate with words.

The only complex part is that the clones send data packets at odd intervals to LOGGER. It is up to LOGGER to queue up the requests sent to it and execute each request when it can. I think that is generally where the issue is occuring, but I can't figure out how to isolate.

If I go through the trouble to decouple the code for an example Im pretyu sure it will work just fine, thats whats driving me nuts.

Only reasons I can imagine to see this

1) File Refs created in a dynamic vi (One that has no link to static MAIN); ex; LOGGER, can go invalid for unknown reasons <-ugly

2) Re-entrant VIs messaging to a dymamic vi, (such as LOGGER ) can somehow cause a file ref created within LOGGER to be dropped. <-ugly

3) A Memory cache issue? <ugly but perhaps the most feasible explanation.

That beer is getting colder in the fridge...

[Kevin P]

Could you post the LOGGER code?

-Kevin P.

[TG]

quote name='Kevin P' date='Dec 6 2007, 02:37 PM' post='39375']

Could you post the LOGGER code?

-Kevin P.

Edit -> Arrrgggg!!! I think I found it! Man! Stupid got me again.!

Kevin, Thanks for suggetesting I upload this to the forum.

It forced me to look really hard and I am pretty sure I found my "issue".

Turns out my hard coded path was sitting in a typedef, was defaulting to empty and my error trap was not set up to shut down the LOGGER state machine immediately.

Ill let you know if it actually solves the problem when i get access to the rig again.

Cold bear coming at ya