Data type mismatch for code from labview 7

[dragondriver]

Hi all,

  I just install a trial version of labview 2012 in my computer for reading the code written in labview 7 in my lab. I am not running any code in labview 2012, I only want to read the code. But I find that there report some data type matching issue. In the old code, there is a AO Update Channel (single-point waveform).vi for outputting an analog signal. I have the value port connected to the value field of SGL type, but it reports that

"You have connected two terminals of different types. The type of the source is single [32-bit real (~6digit precision)]. The type of the sink is Waveform (DBL)"

I also try to set the source as DBL but it doesn't solve the problem. Is that any way to fix the problem instead of modifying the code?

p.s. labview 2012 was installed in WIndows8 64-bit while the old code was written in labview 7 which is installed in 32-bit windows xp.

[RavensFan]

You need to wire in a waveform, not a double representation scalar.

[dragondriver]

Thanks. I know it is something wrong with the datatype. But I just wondering why it is not requiring that in labview 7, that code is running without any problem in labview 7

[RavensFan]

Does the VI actually show up in LV 12?  It sounds like a traditional DAQ subVI.  Did you install traditional DAQ for LV 12?

I don't know if it a polymorphic VI.  (I'm not sure if polymorphic VI's existed in LV 7.)  Let's assume it is and it didn exist in LV7, perhaps the installation in LV12 is not allowing it to select the correct instance of the VI.

If you are using traditional DAQ, I'd recommend converting the drivers over to DAQmx as part of your upgrade from LV7 to LV2012.

[JÞB]

There is no version of NI DAQmx that supports both LabVIEW 7.0 and LabVIEW 2012

LabVIEW 7.0 did not have a Waveform Data type.

Polymorphic vis existed in 7.0 (I believe they were introduced in 6.i or 7.0) 

What are you doing with 10 year old software?

[dragondriver]

You are right, it is traditional DAQ. I didn't find any traditional DAQ for LV 12 online but I simplfy copy the vi's for traditioanl DAQ for LV7, when I open the code in LV12, it report missing some vi (DAQ) and I point it to the vi's I copy from LV7 and it never complain again. The only problem I still have is it keep asking Ivdaq.dll, again, I copy the dll from labview 7 (32-bit OS) but when I point it to that dll, it further report that missing nidaq32.dll. I don't know if that's the reason causing the problem, but if I ignore that warning, the program will be open and all vi's and subvi's will be opened and shown up without any problem except for the issue I post here. The LV12 was installed in windows 8 64bit and I don't where from where I can find the traditional DAQ for my LV12.

[crossrulz]

---

@dragondriver wrote:

You are right, it is traditional DAQ. I didn't find any traditional DAQ for LV 12 online but I simplfy copy the vi's for traditioanl DAQ for LV7, when I open the code in LV12, it report missing some vi (DAQ) and I point it to the vi's I copy from LV7 and it never complain again. The only problem I still have is it keep asking Ivdaq.dll, again, I copy the dll from labview 7 (32-bit OS) but when I point it to that dll, it further report that missing nidaq32.dll. I don't know if that's the reason causing the problem, but if I ignore that warning, the program will be open and all vi's and subvi's will be opened and shown up without any problem except for the issue I post here. The LV12 was installed in windows 8 64bit and I don't where from where I can find the traditional DAQ for my LV12.

---

I'm not sure Traditional DAQ will work on Windows 8.  I'm not even sure it was officially VISTA complient.  That could be your problem.

But you might also want to read through this kb:http://digital.ni.com/public.nsf/allkb/7B916CC4A067997D862574BB000E2AB5?OpenDocument

[crossrulz]

Ok, I just found another kb about a Traditional DAQ beta NI had for VISTA and Windows 7.  But they were 32-bit only!  The point was to allow developers to figure out how to change their programs to use DAQmx instead.

http://digital.ni.com/public.nsf/allkb/8EC9E81C3DE4E619862573930083BD7A

The point here is that if you are going to use a modern OS, you should use DAQmx and a modern version of LabVIEW.

[dragondriver]

The code was written for a system running in our lab for many years. It is such a big system and code are all entangled so it is not easy to have everything transferred to the new version. That's really a headache.

---

@JÞB wrote:

There is no version of NI DAQmx that supports both LabVIEW 7.0 and LabVIEW 2012

LabVIEW 7.0 did not have a Waveform Data type.

Polymorphic vis existed in 7.0 (I believe they were introduced in 6.i or 7.0) 

What are you doing with 10 year old software?

---

[RavensFan]

In that case, you may just want to continue maintaining the code in LV7 with traditional DAQ on an older PC with an older OS.  Of course there will be some point of time where something is going to break and you will be forced to start upgrading.  It will be in a rush with no time to do it properly and you'll be under all sorts of pressure to do it quickly and correctly.  (Good luck with that!)

Rereading your earlier post, you said you just installed LV 12 to be able to read the code.  Copying the traditional DAQ VI's from older LabVIEW was probably a bad idea.  But if you are just doing things to read the code to see what the VI's do, without trying to make it run unbroken, you are probably just fine.  You shouldn't care that much about certain broken wires.  Note that there is a version of traditional DAQ you can install on your LV12 PC.  NI-DAQ and LabVIEW Version Compatibility (for Windows) (Version 7.4.4)  It looks like traditional daq 7.4.4 will work from LV7 to LV 12.  However, there are no guarantees about 64 bit versus Win 8 or anything like that.

Make sure you maintain a safe copy of your code elsewhere.  You don't want to accidentally open a VI in LV12, save it, then be unable to use in in LV7.  Trying to migrate backwards would be a bigger pain than you are already experiencing.  So don't expect to make code modifications in LV12 to save back to LV7.  Theoretically possible, but really not worth the trouble.

I would recommend starting a process to upgrade that code now while you have a chance.  Fix the bugs that needed to be fixed and the previous programmers got around to.  Do it now while you have a chance to prove out everything before releasing it for actual use.  That way you are forced to do it under pressure when the running applications finally break.