Convert CIN to Call Library Function LabVIEW 2010

[MCornwall]

I have some old code that has CIN calls from LabVIEW 7.0. When I open the code, it throws errors because the old code uses CIN; which is not supported by LV 2010.

Here is my problem, the CIN calls are from an old hardware driver that is unavailable. (The developer is not responding and doesn't have the software online) I have the .lsp files that were used to create the nodes but I have no way of knowing (that I know) which lsp is being used in which CIN node. ON top of this, I am not even sure that the Call Library Function node will work with compiled LSP files.

Does NI maybe have a good utility for porting these over?

Thank you!

- Michael

[Tim_S]

You'd be better off asking NI if NI has a utility for porting things over. I'm not aware of any, but then I've not used CIN.

Tim

[MCornwall]

You'd be better off asking NI if NI has a utility for porting things over. I'm not aware of any, but then I've not used CIN.

Tim

Thank you for the response. NI was unresponsive on their forum too. I found a work-around by using different files but never found a way to port over CIN.

[Saverio]

You posted the question on the NI forums yesterday. Please be aware that those are public forums, and the volume of posts there is extremely high. Thus, it is easy for threads to be lost. I am extremely active on the NI forums and I did not even see your thread. This does not mean it got ignored. It simply got lost in the cacophony.

As for your question: you will not even have a hope of doing this without the source code to the lsb. The .lsb files are compiled code, and it's a binary file with a specific format. You would need to go through a lot of steps in order to get to at least assembly language. To get it to C you'd need to do this yourself. However, the disassembly of the CIN code may even be illegal.

You said you don't know which .lsb file goes with which CIN node. Can you guess?

[Val Brown]

I'm unaware of any specific, inherent limitation in either 2010 or 2011 re: the use of CINs. In fact, I have a legacy project that uses one CIN and I've had no problems at all with it in 2010 and 2011. I suspect that the problem is more connected to how you are referencing the resources needed by the CIN.

FWIW, if you can, I'd suggest migrating that CIN -- called in some test program -- through each of the intervening LV releases. Perhaps that might help resolve the problem or, at least, highlight more clearly where the error is really coming from.

[MCornwall]

Val Brown

I'm really surprised that you were able to use the CIN in 2010. When I open it, I get a broken error with the reason that CIN is no longer valid.

Saverio:

I do not have the source. I suspected that I wasn't going to be able to get source from LSB.

NI did end up responding. They do not have a transport utility or methodology.

As of now, I have the problem resolved. I did end up getting ahold of the creator of the driver and he did supply me with updated VI's.

Thank you!

[Val Brown]

Val Brown

I'm really surprised that you were able to use the CIN in 2010. When I open it, I get a broken error with the reason that CIN is no longer valid.

Not only in 2010, but also in 2011. I suspect that, if you had migrated the code version by version as I suggested, then you wouldn't have gotten the broken arrow but I guess it probably also does depend on the particular CIN. In any event it was good that you got ahold of the original developer(s) and they were able to resolve the issue for you.

[Rolf Kalbermatter]

I'm really surprised that you were able to use the CIN in 2010. When I open it, I get a broken error with the reason that CIN is no longer valid.

You didn't happen to go from one platform to another? Remember Windows 32 bit and Windows 64 bit are completely different platforms when compiled code is concerned and CINs are simply compiled object code. Change between Mac, Windows, Linux and VxWorks are anyhow different platforms.

As long as you stay in the same platform, CINs should still load fine in LabVIEW. However I don't beleive CIN tools have been ported to Win 64 Bit so don't expect to be able to create CINs for that platform. To port a CIN you would anyhow need the source code as you need to recompile it.

I do not have the source. I suspected that I wasn't going to be able to get source from LSB.

NI did end up responding. They do not have a transport utility or methodology.

Even if they wanted they couldn't. The actual CIN is just as different as a DLL for different platforms. There exists no good translation to convert a 32 bit DLL to a 64 bit DLL, that I would know of. The solution is to take the source code and recompile. Without source code it's a though cookie.