LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Wire mode bug in LabVIEW 2010?

Solved!
Go to solution

I had an application written in LabVIEW 2009 for a CFP-2220 that stopped working when it was converted to LabVIEW 2010, and I have tracked down the problem to one thing: the software sets the wire mode of the serial port. Calling this method simply disables the whole program. It works when run from LabVIEW...but if you build a startup application it will not even start. Remove the wire mode call - and voila, the application runs as it should.

 

So - I can fix the problem easily by not calling the wire mode method, however this is no solution due to the fact that I need to use the RS-422/485 port in 2-wire RS485 mode.

Message 1 of 5
(2,976 Views)

Hi Mads

 

Which version of the Fieldpoint driver are you using? Would it be possible for you to post a simple example of the problem so I can reproduce it?

 

Best Regards

 

David

NISW

0 Kudos
Message 2 of 5
(2,961 Views)

It turns out that this is an even stranger problem; the serial port init function will ONLY work in the built application if it originates from the vi.lib\Intsr\serial.llb file.  If you do a save as and substitute with original...then you would expect it to still work, it's the same VI, it has just moved...but no (!). Again - there are no warnings, no errors, and everything runs fine in the development environment, but if you deploy and run this application on the cFP-2220 it will only run if the serial port init VI came from that location. Save it to another location (no conflicts caused by this)..build it again, and the application will not start. You can even move the whole serial.llb file to somewhere else and call the serial init file from there - and that's enough to stop it from working.

 

The reason why I though that I had linked this to the wire mode was the fact that I got everything to run when I used the standard serial port init VI...but if I saved a copy of this to another location and added the wire mode to it it stopped working...so I assumed it was the wire mode, because that was the only thing that had been changed that would logically produce any change...the fact that it was moved should not have any effect....it turns out that was wrong.

 

I have a few other variations to test (what if I edit the file directly in vi.lib\Instr, will it work then e.g.? That will not be a good solution, but a good thing to test anyway)...

0 Kudos
Message 3 of 5
(2,950 Views)

This was quite amazing....The RT app works fine if I just use the Serial Init.vi from vi.lib\Instr\serial.llb...but not if the VI is anywhere else...not even if I copy the whole Instr folder to the desktop and then call the serial init function from there...

 

Again - there are no warnings when using the VI or building the app - and everything works fine if in the development environment (and in built apps if you use 2009 instead of 2010), but the built startup application just will not run if the source for the serial init VI is located anywhere else.

0 Kudos
Message 4 of 5
(2,932 Views)
Solution
Accepted by topic author Mads

I found one solution that I can live with...it does not explain what goes wrong, but here's what I had to do to be able to run the serial port init.vi from outside of vi.lib\Instr\ - which in turn allowed me to add the modifications I need (setting the wire mode) without editing a library function:

 

I had to flatten it, i.e.replace all of its sub-VIs with their contents...I could have tried the inline-feature, but did this manually to be safe.

 

This perhaps indicates that something goes wrong with the linking when the software is compiled with RT...but it happens without producing any conflict errors or anything. A startup.exe is produced - but it is not able to execute.

0 Kudos
Message 5 of 5
(2,922 Views)