Jump to content

Simple FIle I/O in a Queue throttled loop


TG

Recommended Posts

post-2402-1196740272.jpg?width=400



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
Link to comment

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

Link to comment

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.

Link to comment

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

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..

Link to comment

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.

Link to comment

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...

Link to comment

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 :)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.