I've got some weird stuff going on with a cRIO project I'm working on wanted to get some opinions on it. The basic architecture is a set of classes that do some process. That process registers with a server. The internal data of the process is held in a DVR and the server get's access to that DVR. Clients use TCP to ask the server to do something, the server makes a call against the classes DVR and returns a response to the client.
To simplify the issues I'm seeing I created a class that internally just increments an integer every 500ms. The client asks the server what's the current count, the server asks the Counter class and returns the answer to the client. This works perfectly fine when running the VI in the IDE. When built it connects, will get the JSON message back, but always gets a default value from the DVR call (zero, in this case). As soon as I open a remote debug panel to the cRIO, everything is working. The count is correct, the client calls work, just like normal. As soon as I right-click, close debug, it goes back to zero. Open debug works, close debug, back to zero. I know the DVR isn't getting dropped because the count continues to increment while not in debug, the process is still running happily with no issues.
Here's a few screenshots of the code;
Count Class process (get the count, increment, write it back to the DVR) - Counter Class process
You can see the DVR vi's are actually vim's using a cast. I can't imagine that's the issue.
Server Side call - Server Side calls
All this does is get the count from the DVR (same as above) and wraps it in JSON and passes it back to the client as a JSON string.
I also implemented an Echo class that ignores the process and DVR's, it just takes whatever string you sent form the client to the server and passes it back with a prepended "@echo". This works when running as an executable with the debug turned off so I know the client, server, and the server/class calls are all working as expected.
Any thoughts here would be welcome, thanks.
edit: I added the any possible errors coming from the variant cast to the JSON reply. When the debug is open there are no errors, when the debugger is closed it throws error 91, but the in-place element structure reading the DVR does not throw any errors. How can a variant not exist until a debugger is opened and than it magically exists?
edit: the internal data dictionary is a wrapper around a variant attribute, I wired out the "found?" terminal all the way out to the JSON reply and if the debugger is open the attribute is found, but not if the debugger is closed. Anyone have issues with Variant Attributes in Real-Time?
So I'm working on making a certain vi a remote panel. However this vi is quite complex with a lot of property nodes events which makes remote panel connection can be a bit unreliable cross-site because of the amount of data being transferred.
What i'm trying to do to solve this is use a secondary vi that grabs an image of the first vi's front panel at a given frequency so that any changes are seen with out having to send too much data back and forth between the server and client. Basically all we should see is the change in pixels. When a user clicks on the image on this secondary vi i would like to simulate a click on the first vi at the same co-ordinates which should give me full control. I would use the secondary vi as the remote panel instead. I'm guessing this is how remote desktop would work?
I have looked into simulating mouse click events using the User32.dll and it works great > http://digital.ni.com/public.nsf/allkb/9BB3211F3469623649257360000E272C
However my problem is that this vi may not be the top vi or may be transparent at times. So my question is, is there a way of simulating a mouse click on a specific vi even if its not on top or hidden?
This idea may be too crazy to work and in that case any suggestions are welcome.
Thanks in advance.
I'm having some issues with a LabVIEW driver I'm writing for a Mensor CPC 6000 pressure controller.
I open the TCP Connection using the LV "TCP Open Connection" VI, and can then successfully read various values from the Mensor, such as "id", "gasDensity", etc., using the "TCP Write" and "TCP Read" VIs wired with the connectionID refnum. I save the connectionID in a shift register and want to use this connectionID to write and read values the next time the VI is executed, however as soon as I perform a "statusUpdate", "TCP Write" returns Error Code 1. Tests already performed
I've confirmed that I'm not accidentally closing the reference in LabVIEW. I've confirmed that the connectionID is saved correctly in the shift register (by casting it to type U32 and comparing outputs and inputs after each execution) If I open a new connection and immediately perform my "statusUpdate" the expected values are returned possible cause?
is LabVIEW or Windows automatically performing some clean-up in the background leading to an invalid reference, or is something with my hardware setup funky?
Hardware setup: PC running Windows 8 and LV2016, directly connected to Mensor CPC 6000 using a crosswired ethernet cable.
Mensor IP Config: Address, 172.18.149.201, Subnet Mask: 255.0.0.0, Port: 6000
PC IP Config: IP Address, 172.18.149.1, Subnet Mask: 255.0.0.0, Default Gateway 172.18.149.1
The driver is a simple affair (see attached VI snippet for the VI which reads strings from the Mensor)
Any help would be appreciated!
I am currently developing a scope that displays live data from a test rig. The scope is accessible via remote panels. Tests normally run for many hours at a time, when monitoring the scope after several hours of running I notice that the data on the chart displayed via the remote panel is not in sync with what can be seen on the actual 'server' vi. The delay also seems to be getting bigger as time goes on. I also display the current data points in an indicator; however these seem to be in sync and 'current'.
The scope is part of a built application and I am using labVIEW 2012 f3 to develop it.
I know that there is an issue with synchronizing front panel appearances when using remote panels in built applications but I think I have got around that by re-applying panel changes when a new client connects. Also on every execution of the VI, I defer panel updates make all my updates to controls including the chart in question, force draw the chart and then re-enable panel updates.
I would really appreciate if anyone that has experienced this sort of issue could share a possible solution/work around.
Thanks in advance.