LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 6 when using Write PNG File.vi

Solved!
Go to solution

Apologies that I can't attach code directly, but here is the code in question.

 

The folder is created (if needed) in GetFilePathForSnapshot, which outputs the path, which is then wired into Write PNG File.vi as shown in the second snip.

 

That the Write PNG File produces the same error no matter how many times it is attempted (with the same folder) suggests to me that the timing of creating the folder and then attempting to use it is not the issue.

 

I'd be glad to be proved wrong though!

 

EDIT: I was a little worried that I use the "created path" output of the "Create Folder" as it may produce <Not a Path> if the folder isn't created. But my debug prints confirm that the path being passed to Write PNG File.vi is the correct one even when Create Folder returns an error to prevent overwriting an existing folder

Download All
0 Kudos
Message 11 of 20
(893 Views)

Can you show any screenshots of the error dialogs so we can see what they say?

 

The WritePNG is based on the error wire from Take Snap Shot.  Any chance that Take Snap Shot is generating an error when it is running in EXE?

 

EDIT:  I see your file path in the Save Snapshot is coming from a local variable.  Where is the terminal for that?

0 Kudos
Message 12 of 20
(883 Views)

Here's a screenshot. I believe it shows that the error is definitely sourced from the Write PNG File vi itself?

 

My Take Snapshot VI can only return an error due to errors in Getting an Image from the clipboard (this image is then converted into a pixmap to be used by Write PNG File) - I wouldn't expect to be able to get an Error 1 error from that, I believe? (Snip attached of relevant code - I added an extra Error Reporter there and ran the code to be sure, and can confirm no error coming out of the Clipboard.Get Image call).

 

The very odd thing is that occasionally it just works, but most of the time I get this error. Which in my (limited) experience points towards race conditions / OS shannigans.

Download All
0 Kudos
Message 13 of 20
(879 Views)

Oh, the local variable's terminal is on the front panel of this VI. It is set before any of this code is run, and is otherwise read-only.

 

My debug prints show no issues with getting the right value of this path. (when Write PNG File errors, I print the path that was given to it, as well as the one it outputs, to be sure)

0 Kudos
Message 14 of 20
(874 Views)

Actually the terminal is somewhere else on the block diagram.  I assume you have either a control or an indicator on the front panel.  Why did you use a local variable rather than the terminal?   I'm not suggesting it is a problem, but seeing a local variable gets me suspicious of race conditions which is why I asked about it.

 

Error 1 still indicators some issue with the path.  Can you put an indicator on the path that goes to the Write to PNG so we can see what it looks like?

0 Kudos
Message 15 of 20
(868 Views)

"Actually the terminal is somewhere else on the block diagram" - aha you caught me out! The terminal is somewhere else on the block diagram, the indicator is on the front panel.

 

I've added an indicator on the path. Results attached. The "Output File" is slightly different in each example, but this is only because it is generated based on the time the program starts.

 

Can you spot anything I've missed which is wrong with the path shown?

 

Additionally, my message log contains this "04:15:52 PM - C:\Users\James.Veale\Desktop\temp\20190328 161536\Chip 0.png C:\Users\James.Veale\Desktop\temp\20190328 161536\Chip 0.png Image did not save." - which is what I'd expect based on the snip of code I showed you.

0 Kudos
Message 16 of 20
(869 Views)

I'm starting to run out of ideas.  I was hoping I'd see something in those paths that could explain it, like how I managed to see the space in the path in the original problem.  But I'm not.

 

My next thought is to replace the local variable with a file path constant, and make sure you can browse to it.

Some other things might be to try using Check if File or Folder Exists?  and List Folder under the Advance File palette.  Let LabVIEW give you some more information about what is in that directory.

 

 

0 Kudos
Message 17 of 20
(862 Views)

I really appreciate all the help so far.

 

Before attempting what you suggested (file path constant, check if file or folder exists, etc), I decided it would be a good idea to create indicators for my picture and pixmap and I've found something. Despite my assumption that Error 1 was specific to file paths, I remember it's about any kind of invalid input. It turns out that in my executable it is the Take Snapshot vi which is misbehaving, despite working fine in the development environment. It's outputting an empty picture and so the pixmap produced by Picture to Pixmap is useless for Write to PNG File.

 

So I need to turn my focus onto why Take Snapshot is misbehaving in a built executable - which is a much more daunting task for me, as it involves calls to the Windows API and all the complication that seems to entail.

 

A new question may be in order, but I've attached a screenshot of the offending VI.

 

Essentially, I have a live feed from a webcam in a child window of the front panel's window - the Take Snapshot VI asks Windows to take a copy of the feed in that window (the window is referenced by the "handle" input, which is returned by the Windows API in response to a previous request to create the window). After a short wait, it then grabs that image from the clipboard and outputs it so the rest of the program can save it appropriately. This is all because there's no budget in this project for the dev or even runtime licenses for NIs IMAQ stuff. I'm very aware it's not the cleanest way of acquiring an image from a generic webcam, but it has been working well (at least when run in the development environment). I can see this is a lot more involved than a file path error!

 

I've also attached a screenshot of the SendMessage vi, but that is used elsewhere in the program with no issue so I don't think there's any issue there.

 

 

 

I'm not sure how this could be being effected by running in dev environment vs running built...

 

I have noticed now that if I copy something else (e.g. some text from the front panel), everything succeeds - except the image saved is an image of the string I previously copied. So I don't think the paste (Clipboard.Get Image) itself is broken.

Further, if after the failure I open paint and paste there, I get the image that should have been saved - so it clearly has been copied at some point.

 

This would point me to a race condition in LabVIEW, (or perhaps not giving Windows time to complete the copy?). However, if I then continue to take another snapshot I would expect to see my previous image saved, and the new image pasted in paint if I attempt manually. Instead, I get the same result as before - an image of the previously copied string saved, and the latest image pasted if attempted manually in paint.

 

I hope the above makes sense.

 

Let me know if you can make any suggestions here &/or if I should start a new question...

Download All
0 Kudos
Message 18 of 20
(849 Views)

This issue has now been asked as its own question here.

 

The new question includes an attached project which is the minimum required to show the issue in action.

0 Kudos
Message 19 of 20
(828 Views)

Solution here, if anyone needs help on this in the future!

0 Kudos
Message 20 of 20
(810 Views)