05-03-2011 10:50 AM
Ahhh that is trickier. The Import Library Wizard does this in a way, but I doubt you can get at the internal methods easily to extract only the structure parsing code. I did in the past something like this, in fact almost a complete C parser, excluding support for function pointers, but that code is not extractable easily to be posted here. It was a challenging thing to do and I learned a lot about C syntax that I never intended to learn Getting the inherently recursive C syntax into an array of data elements was quite some work.
I think a better solution would be to find an external C to XML or whatever converter library and then parse that one in LabVIEW and using scripting to create the cluster.
05-03-2011 11:06 AM
The flattening and unflattening is trivial, the issue is maintaining a 1 to 1 correspondence between the C header, and a the LV cluster.
06-08-2011 01:07 PM
Installer bug? Installed v2 on Windows 7 64-bit with LabVIEW 2010 64-bit. In the folder installation step I specified the LabVIEW 2010 directory as "C:\Program Files\National Instruments\LabVIEW 2010". The installer promptly ignored me and installed it in the "C:\Program Files (x86)\National Instruments\LabVIEW 2010" directory.
06-12-2011 09:33 AM
Hi there! i need some help with my project, i have just asked in other post but i guess they didn't find the error, and maybe here in the STM section somebody can help me. Let me introduce the project itself, it consist in making a PC1< ------>PC2----->Projector communication. So i have now everything except communicatin betwen PC2 to PC1 and sending strings readed by RS232 to the PC2. I don't know really what is happening smercurio_fc tried to help me well but i have tried the timeout and i guess is not the problem at all. Maybe i have made some mistakes or maybe i am not doing well something, would you mind seeing my code and try to help me? Thanks in advance and keep up the good work!
This is my post: http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Rs-232-communication-with-a-projector/td-p/15...
06-13-2011 11:37 AM
smercurio_fc:
We haven't tested the installer on Windows 7 64 bit, so thank you for the feedback. The next time we revise the library, we may move to a VI Package to avoid having to maintain our own installer. In the mean time, you should be able to manually install by copying the folder into your user.lib and restarting LabVIEW.
06-15-2011 09:15 AM
I have a RT system that I am setting up and I am replacing shared variables with STM reads / writes. My server is a headless system and will be running most of the time. The client needs to be able to start and stop many times during a test run.
The issue that I am having is that once the client reads the metadata, it is no longer available to read upon the next run.
Possible solutions:
1: The server could have the ability update the metadata on a on-call basis.
2. The client could read the connection ID / metadata once, store it to a file, and retrieve it on subsequent runs.
Any other suggestions?
-Ken G
06-15-2011 09:42 AM
Are you getting error 60 when you try to re-open the listener? If so, this has nothing to do with the meta data, but rather with the fact that you are placing your server-side TCP socket in the TIME_WAIT state. You can probably remedy the problem by closing the connection from the client side and only closing the connection on the server side once your recieve error 62 or 66.
06-15-2011 10:02 AM
OK, so you are suggesting that I stop the server each time the client stops?
BTW, the error on the client-side is 56 (timeout) coming out of the "read MetaData" vi.
(after more debugging...) I do now see error 66 on the target-side "STM Write Message" vi .
06-15-2011 10:03 AM
@ryank wrote:
smercurio_fc:
We haven't tested the installer on Windows 7 64 bit, so thank you for the feedback. The next time we revise the library, we may move to a VI Package to avoid having to maintain our own installer. In the mean time, you should be able to manually install by copying the folder into your user.lib and restarting LabVIEW.
Yup, that's what I did. Figured I'd give some feedback in case the library gets updated along with the installer.
06-15-2011 10:26 AM
You don't need to stop the server, but each time the client stops you will need to cleanly close out the TCP connections. TCP is a strictly connection and state based protocol, where both ends of the connection constantly know what the other end is doing, you cannot, for example, re-open a connection from the client without first closing the corresponding connection from the server. There are a number of ways of handling this, the easiest is to always terminate the connection from the client side and then monitor for error 62 or 66 on the server side, close the connection, and loop back around to a TCP listen. You'd then re-transmit the meta data each time the server establishes a new connection.
A couple of other random thoughts:
1. While we typically transfer the meta data in order to make it easier to maintain the application, there is actually no requirement to do so, if your meta data isnt determined dynamically (which it rarely is) you can use constants for the Meta Data on both ends of the connection, you just need to remember to update one whenever you update the other. I don't think this will solve your problem (once the server is returning error 66 nothing is going to re-establish that communication other than closing the connection and listening for a new one); however, it may help to simplify and speed up your re-connect procedure.
2. If you want something that is not connection based, you could just use UDP rather than TCP. If your data needs to be delivered you'll need to implement an acknowledge, but in some cases that is easier than managing the TCP connections.