Occasionally, Jpg File Does Not Load From Disk File

[SteveMyres]

There's an image file that's being frequently FTP'd to my HMI machine, and I periodically refresh a named component with that image, using Component.MyComponent.LoadJPEG(). Every 10 loads or so, I get a red X instead of the image. I assume this means the image is currently being written from the remote source and DAQ Factory can't read it.

What's the best fix for this issue? Rather than periodically reloading the image unconditionally, check the time stamp and only reload if different from the previous timestamp? This might guarantee that the remote client had completed writing the file.

[AzeoTech]

That's a tough one actually. Really the only reliable way is to have the FTP program create a new file every time instead of overwriting the same file. Ideally make it use the same prefix, and either a time stamp, or just increment a number (image1.jpg, image2.jpg, etc). Then you can use the File.getFilePathList() function to get a list of all the images in the folder. You'll want DF to load the next to most recent one. So if image1 and image2 are in the folder, have DF load image1.jpg. Once you have 3, you should delete the oldest. So, if you have image1, image2, and image3, you should assume image3 is in process, load image2 and delete image1. You don't want to delete image2 until image4 is found because you have no way of knowing that image3 is complete until image4 appears. Also you'll probably want to make the delete routine delete all images from the 3rd one back. That way if DF is stopped, but the ftp continues, you don't end up with lots of extra images. So, if you have image1, image2, image3, image4, you'd load image3, and delete 1 and 2.

[SteveMyres]

OK, thanks!

[SteveMyres]

I assumed the failure to load the image occurred when DAQ Factory was trying to read while the file was being rewritten, but I've since noticed that the behavior (occasional failures to load) is the same even when the remote client isn't uploading the image files (so the same copy of the file is being loaded repeatedly).

What might cause this? Might storing the file on flash rather than a mechanical disk, help? Not sure if there's room (or budget) to add a SATA flash disk, and I doubt a flash thumb drive is any faster than a mechanical HDD once you allow for the fact that's it's throttled by the USB interface.

[AzeoTech]

Most likely the FTP failed part of the way through leaving an incomplete and therefore corrupted Jpeg file which DF couldn't load. Storing the file other places isn't going to help.

[SteveMyres]

Nope. The same exact file loads at least 90% of the time. The FTP client (a vision inspection camera) just refreshes the file with the same name continuously, so when it's not doing so, DAQ Factory is just periodically reloading the same file, and it succeeds most of the time, but every so often you get the red X momentarily, but then the next try succeeds and the image is refreshed. Puzzling.

[AzeoTech]

Are you sure that isn't happening right when the camera is updating? Or that the camera didn't completely upload a file, and then succeeds before the next refresh from DAQFactory?

[SteveMyres]

No, because both successful and unsuccessful loads occur when the camera isn't writing.

If it were a contention issue, it shouldn't occur at all when the camera isn't writing, and if it's occasionally writing a corrupt file, then it should always be either good or bad, whichever type file you have, till the next time one is written.

For example, the file it's been loading was dated December 3, but still has the problem, but still loads most of the time.

[AzeoTech]

Try using system.delayUpdate to ensure that the file isn't loaded in the middle of a paint. It'd go something like this:

system.delayUpdate()

component.myComponent.loadJpeg(...)

system.resumeUpdate()

You probably should actually use a try / catch block:

try
   system.delayUpdate()
   component.myComponent.loadJpeg(...)
catch()
   ? strLastError
endcatch
system.resumeUpdate()

[/CODE]

[SteveMyres]

Oh, OK, that makes sense. That must be what's happening. I'll give that a try.

Thanks!

[SteveMyres]

That must have been the issue. I tried that and it seemed to fix the issue. I was only at the site for a very few minutes after the change but it would normally have been long enough for the problem to manifest.

Since the camera wasn't storing files, it doesn't necessarily mean that we won't have a contention issue when we start it doing so again, but we did have an issue independent of the camera and this appears to solve it.

Question about a related issue -- the image is displayed on several pages (and not in the same spot so I can't do it as an overlay). When I put the panel object on the various screens and named all the instances, I assumed the component names had to be unique, so I gave them all different names and the JPEG refreshing sequence checks which screen is displayed and updates only the relevant component. I've since noticed that it's possible to name more than one component with the same name -- not to group components and then assign a name to the group but to individually apply the same name to multiple components.

What are the implications of doing so? If all the components on all the pages had the same name it would certainly simplify the sequence; would it be slower? While you can physically apply the same name to multiple components, does it cause a conflict to do so? In short, is it better to leave it the way it is or rename the components so they're all the same and simplify the sequence?

[AzeoTech]

If you name components the same, then you can change their variables with a single call. However, I don't think it will call a member function on all the components, so loadJPEG() would only execute on the first component found. You'd have to try it, but I'm pretty sure that is true.

Personally I'd still use overlays, for two reasons: 1) once a jpeg is loaded, its converted to an uncompressed bitmap. This is a big memory hog, especially if you have it 4 or 5 times on separate pages. 2) using your method, if the user changes to a different page, they will get an older image because the last update adjusted the one on the last page they were at, not the one they are on now.

To resolve your positioning issue, just programmatically change the position as the user changes pages.

[SteveMyres]

Good idea -- don't know why it never occurred to me!