Write JPEG file error on Compact FieldPoint

[Mons]

Hello!

I'm using Compact FieldPoint 2120 and LabVIEW 8.2. I'm trying to capture an image of a front panel and to save it into Compact FieldPoint using the "Write JPEG file". Unfortunately, it gives the error 1.

I indicated c:\<jpeg_file_name.jpg> for the path.

I switched the target to "My computer" and the code works correctly.

Is that a problem of the path or VI Write JPEG file cannot be impemented on Real-Time target, such as Compact FieldPoint?

Thank you!

[Graziano]

Hi!
   How do you capture jpeg image?

   Real-time has several unsupported LabView features, you find them in "LabView Real Time Module User Manual", section 1-5, maybe you find it useful.

   Have a nice day!

graziano

[RavensFan]

Often, (usually? always?) VI's on a cFP will not have a front panel because that platform is designed to be a headless system.  So although a VI is built with a front panel, the cFP doesn't compile it or use it in operation.  So there is no front panel to publish.

[Graziano]

Hi Ravens fan,
   I don't agree 100% , since some things are kept, for example, you can have a front panel, and use simple references to front panel LEDs, and use it in embedded application.  Altough this is not fully supported as in desktop-PC LV-application, you can have some functions.  The line between what you can and what you cannot do isn't really well defined from NI.

   For the LED stuff, I discussed it in another thread, when I was looking to handle complex front panel objects (clusters, rings... actually, I don't remember!).  I was able to get LEDs value from reference, but not more complex object's.

graziano

[Mons]

Well, that's true that Real-Time does not support Write JPEG file (this is the first problem). I'm using now Write BMP file insteed. The second problem, verified also in my practice, is that the Front Panel does not exist too on Compact FieldPoint.

My aim is to develop web-interface to deal with the Compact FieldPoint from any computer. That is true that it has its own built-in Web-Server, but it doesn't have a script-executive environement. My idea was to create a custom "web" server running in parallel with the principal Web-Server to execute VI scripts.

For that purpose I used TCP Listen -> TCP Read -> TCP Write runing on the port 82. I can send from any browser the request http://<IP address>/<script.vi>?<params> and my custom server parses the request and executes the <script.vi>. Then to avoid the problems with HTTP protocol I write the redirecting request to the port 82 like <meta http-equiv="Refresh" content="0; URL=<result_page.html">. So, It works.

The result_page.html must represent the acquired data from the Compact FieldPoint channels. So, I execute a requested script to show the specified data into Graph waveform and then to take a snapshot and to save to the Compact FieldPoint. Then the result_page.html contains the link to the saved snapshot picture.

Once executing the requested VI script, the Invoke Node gives the error 1003 stating that "the VI is broken etc...". I think that is because of the script attempts to take a snapshot of a panel which doesn't exist...

Maybe somebody has an idea how to view the acquired data in browser ?


Message Edited by Mons on 07-10-2008 06:06 AM

[Joeri_Wingelinckx_NI]

Hello,


"Error 1003" refers in most cases to missing files on the target..
I don't know if your already did, but searching for "Error 1003" at NI.com/support returns about 20 knowledgebases. 
Here are two who are closest to your problem:
Error 1003 When Using VI Server to call a VI on a Real-Time Target: 
Error 1003 When Using VI Server in a LabVIEW Application
Why Do I Get an Error When I Run My VI On My Real-Time Engine Remotely Using VI Server? 

Hopefully this helps you to find the cause of the problem.

[Mons]

Thank you for your message! Actualy, the first link is right my case. I also remarked that when the VI to execute is opened, I don't get this error. Suraly, to resolve this problem, the entire application has to be builded into package.

But the other interesting thing is that when I invoke the VI from the Compact Field (this VI has been removed from the project, but uses a global variable HTML_CONTAINER), it runs without problem. I suppose that is because this global variable HTML_CONTAINER is loaded automaticaly with my custom server into memory.

I also want to unify any VI-"script" execution on real-time target. The VI-scripts writes the result to HTML_CONTAINER and the server VI reads the HTML_CONTAINER and transmits the result to the browser through the TCP Write.

Should I develop all the VI-scripts in the same project or can I create another project with the same name of global variable (in case when the files of the main project are unvailable)?