IMAQdx datatypes in LV8.2 & LV2009

I've been converting a project containing IMAQdx functionality from LV8.2 to LV2009 and run up against a problem. I've narrowed it down to the registering a Frame Done event using the IMAQdx Session, and then trying to access the dynamic variables in that event.
This is the code in LV8.2:
(I know it won't actually run, but notice that the CtlRef indicator, whilst being coerced, is actually accessible)
Exactly the same bit of code in LV2009 gives a broken wire error, as follows:
The error on the wire is "You have connected two terminals of different types. The type of the source is User Defined Refnum Tag. The type of the sink is typedef 'IMAQdx.ctl' IMAQdx (IMAQdx, IMAQdx)."
Poking around a little, I have tried wiring a Property Node to the CtlRef event node, but I can't work out which property to use to get the camera reference. Any ideas? Is this the right way to fix this problem? Or is there something else I've not spotted?
I've attached the VI for ease of checking (LV8.2).
Thanks for any help!
Solved!
Go to Solution.
Attachments:
Test_IMAQ.vi ‏8 KB

I see the same behaviour, let me check what's going on here.
But you could do it also as follows:

Similar Messages

Save for previous error on FPGA vi (LV2009 - LV8.6)

Hi all,
I have an RT project i want to back save from LV2009 to LV8.6. When trying to save for previous, all FPGA subVI's are saved correctly but the top level FPGA vi returns error 1536:
LabVIEW: To save a password-protected VI for a previous LabVIEW version, you must enter the password.
However, no VI is password protected :-s
All other top level VI's in the project referencing the FPGA VI also return this error.
I searched this forum but found no similar topic, so maybe i'm missing something
Can someone please help?

I am getting the same error. LV 2009 on Windows Vista. There are only 4 VIs (FPGA Main, FPGA subVI, Host Main, Host SubVI) and a Shared Variable Library file. The SV library file and on the FPGA subVI get copied into the new directory along with the LVbit file but nothing else. I am not even sure what VI is having trouble on.
Joji

Lecroy 9310 downconvert LV2009 to LV8.2

Hello all,
I would like to downconvert a Lecroy 9310 oscilloscope driver from the LV2009 version to LV8.2 (link to driver page: http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=E3B19B3E9608659CE034080020E748... I am also wondering if this driver works for an "old" Lecroy 9310, as the driver description mentions a digital oscilloscope, when mine has a cathodic screen.
ETA: direct link seems broken, here is the link to the driver page (I need the Labview driver, not the LabWindows): http://sine.ni.com/apps/utf8/niid_web_display.model_page?p_model_id=12187
Solved!
Go to Solution.
Attachments:
lc930x1x.zip ‏1299 KB

Thanks for this quick answer !
I can open the driver VI, but unfortunately all the subVIs are missing, I suspect they where missing from the original driver (LV2009) too (I'm especially interested in the "LCDSO Read Single Wave").
I don't know if these subVIs are standard components in LV2009. The surprising thing is that looking at the front panel design, this driver seems quite old (before LV8.2 anyway) and would then have been upgraded only by compilation with newer Labviews. It should then be self-sufficient in LV 8.2 ?
I tried to find these subVIs online, but they are only referred to in old forums posts pointing towards unavailiable NI driver download pages (I guess the old drivers are replaced by the new).
Do you know where to find these subVIs ?

VI Conversion from LV5 -- LV2009 (or LV8.5)

Hello,
could someone please convert the VI so that I can open it with LV 2009 (of LV8.5)?
Thank you very much!
Solved!
Go to Solution.
Attachments:
MonoMove.vi ‏65 KB

All of the subVIs are missing. Without them the VI is pretty useless. The subVIs are from some library called "hr630".
You should post this in the Upconvert VI Requests thread.

Convert LV2010 vi file to LV8.5 or LV2009

Kindly convert this vi to V2009.
Thanks,
Mathan
Solved!
Go to Solution.
Attachments:
GetUID.vi ‏31 KB

Here you go
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Attachments:
GetUID.vi ‏24 KB

Error - 1074360266 occurred at IMAQdx Open Camera.vi

Hello,
We're having issues with our LabView vision system; the VI is able to "run" with an unbroken arrow, but there is an error that appears:
"Error - 1074360266 occurred at IMAQdx Open Camera.vi" with a possible reason of "NI-IMAQdx: (Hex 0xBFF69036) Unable to attach to the kernel mode driver"
For a little background, we had originally programmed the VI in LV2009 (where it worked fine), but the customer upgraded to LV2010 (where it now comes up with this error), so it would be logical that this has something to do with the problem. Also, we're using two Basler A601f cameras via Firewire connections, which are both recognized by Basler's Pylon Viewer software, so we're fairly certain this is a LabView-only problem.
We've tried reinstalling the Vision Acquisition Software drivers, but that didn't fix the issue, so we're kind of at a loss.
Any help or pointers are appreciated, and I apologize ahead of time if I left out any pertinent information. Thanks.
Ben
Solved!
Go to Solution.

Hello
Sorry if this isn't the right place to post this question, but I'm new here.
I have a similar problem, I'm trying to operate a Basler A601f camera with Labview trough a IEEE 1394 connection.
At first I could see the camera in MAX, and manually grab images, but when I tried to create a labview project, it wouldn't recognize my camera. Also, the remote systems tree in MAX wouldn't show anything.
I tried to do a full re-instal of all NI software, but things got worst. Now MAX can't detect the Basler camera either.
Also, when I select Devices and Interfaces in MAX, a "Unexpected Internal Warning" appears.
Anyone can give me some advice on how to solve this? If you need more specific details just ask.
Thanks in advance!

How Do I Convert LV7.1 Datalog Files to LV8 Format?

I have several LabVIEW 7.1 datalog files that generate Error 71 (File data type conflict) when I try to open them in LabVIEW 8 using the new Open/Create/Replace Datalog vi with my original typedef constants wired to the record type terminal. Likewise, my original LV7.1 code recompiled in LV8 often generates error 116 (unflatten or byte stream read operation failed due to corrupt, unexpected, or truncated data) or error 4 (end of file encountered) when randomly accessing records in the LV7 datalog files, presumably due to changes made to the datalog file structure in LV8. I recall one time when a dialog box popped up asking if I would like to convert the file to LV8 format. Since this was a file currently in use on the server by LV7.1 clients, I had to reply no. With copies of the datalog files now on my hard drive ready for conversion, I haven't seen the conversion dialog box pop up again.
How do I convert the LV7.1 datalog files to LV8 format?
Thanks,
Larry

Good afternoon Larry,
Thanks for posting!
The Datalog file support in LabVIEW has changed, but the underlying
principles of the technology remains the same.
Converting to the new format should just involve converting a few VIs to the new Datalog-specific versions. As you can see, the new Datalog VIs appear in
their own sub palette in 8 which will help keep things simple.
Before we address the concerns with the errors, let’s first
make sure that the code has been properly converted.
To convert your VI to the new format:
1)      Replace
the Open File VI from LabVIEW 7 with an “Open/Create/Replace Datalog” VI in LabVIEW
8. Keep your type constant or control
wired to the “Datalog Type” input.
2)      Replace
any “Write File” VIs in LabVIEW 7 with “Write
Datalog” and triple check that your data matches the datatype wired into the
open exactly.
3)      Replace
any “Seek” VIs with “Set Datalog Position”. The input to this VI is the number of records
to advance (check the mode set by the “from” parameter).
4)      Replace
any Reading VIs with the corresponding “Read Datalog” VI.
I suspect that if you are receiving errors saying that the
end of file has been encountered it is a result of a bad input to the “set Datalog
position” VI. I attached a basic example
of writing a Datalog file in LabVIEW 8, and reading the results. The rest of the functions in the new Datalog palette
should be pretty straightforward.
Does this help? I
would be more than happy to answer any other questions on this if you need any
additional clarification, or if this response does not address your question.
Travis M
LabVIEW R&D
National Instruments
Attachments:
Datalog8.zip ‏30 KB

How can I deny write access to datalog files for all but one process in LV8?

In LabVIEW 7.1, wiring the deny mode terminal of Open File.vi with a Deny Write Only enum constant was an effective means for ensuring that only one process could write to a datalog file at a time. In LabVIEW 8.0, Open File.vi is no longer available and the new Open/Create/Replace Datalog vi does not provide a deny mode terminal. Also, the new Deny Access vi does not support datalog files. Furthermore, the Set Permissions vi is an unsatisfactory solution because under the Windows operating system, it simply sets the Read Only file attribute. This is inadequate because I have demonstrated that it is still possible for two processes to open a datalog file with read/write access before either one has had a chance to set the Read Only file attribute in order to lock out the file. If a process sets the Read Only file attribute first, then it can't open the file with read/write access for itself.
Does anyone understand the file mechanism by which deny mode used to work with the old Open File.vi? I wish to restore the functionality I had in LV 7.1 in my LV 8 programs.
Thanks!
Larry

Larry Stanos wrote:
I appreciate the
empathy from Rolf, but I'm hoping that someone may have written one or
more vi's containing CINs that call Windows 2000/XP file access control
library routines. At least I'm assuming that is how the deny mode
input to Open File.vi used to work in LV7.1. The Microsoft
Developers Network on-line documentation on Access Control http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/access_control.as... is
daunting to put it mildly. But even if a set of CINs has not
already been coded, perhaps someone could point me to the specific set
of calls I need to make to absolutely guarantee that no two
clients can simultaneously open the same file with write privileges. Unfortunately
the elimination of deny mode functionality for datalog files in
LV8 has sabotaged my commitment to a March 1 release date because it
would also be impractical to convert everything back to LV7.1 at
this point. Sincere thanks to anyone who can help me out here!
Unfortunately
the functionality you mention does not work in the way the deny mode in
the LabVIEW nodes works. Basically that deny mode is converted to an
according FILE_SHARE_READ/FILE_SHARE_WRITE value and passed to the
Win32 API CreateFile function. This is more or less the only place
where you can define a global share (or deny) access to a file. That is
also why the Deny Access node online help is talking about that the
file is reopened.
But I just retried what you had tried to do, and low and behold it
works with wiring a datalog refnum to Deny Access. What is important
here however is that you do need to wire a datatype to the record type
input of the Open/Create/Replace Datalog node. Otherwise you can't
connect the resulting datalog refnum to any other file function, since
it is an incomplete datatype.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Warnings when I downconvert from LV8.6 to LV8.0

I tried to downconvert some VIs from LV8.6 to LV8.0.
For this VI, after "save to previous version", I received those messages:
    The object "Multiply" does not support output configuration in the previous version.
    The object "Multiply" does not support output configuration in the previous version.
    The object "Subtract" does not support output configuration in the previous version.
    The object "Add" does not support output configuration in the previous version.
    The object "Multiply" does not support output configuration in the previous version.
    The object "Divide" does not support output configuration in the previous version.
    The object "Subtract" does not support output configuration in the previous version.
    The object "Divide" does not support output configuration in the previous version.
    The object "Divide" does not support output configuration in the previous version.
I don't have with me LV8.0 and I want to know how to manage those warnings.
Jean-Marc
LV2009 and LV2013
Free PDF Report with iTextSharp

No, these warning can be safely ignored unless you have manually configured the output type of these functions to be different from the default (which is "adapt to type"). Even then, it is probably not a big deal and you could insert an conversion bullet if needed.
In newer LabVIEW versions you can define the output type via the properties dialog (right-click...properties...output configuration). For example you could define that the multiplication between two DBL would result in a I32 output. If you do this, the output terminal will get a blue dot.
In a better world, these warning should only occur for nodes where you have actually configured the output. Currently, they seem to appear always and for no good reason other than confuse the newcomer. They simply alert you that the downconverted function has slightly less functionality. This is irreleveant if you did not use the functionality in the new version.
(See also)
LabVIEW Champion . Do more with less code and in less time .

Open a different vi than the startup vi from a build application in LV2009

When building an application (exe file), I have to select a vi as "statup vi" in the build specification. This vi opens its front panel and executes when I execute the application.
But I can still open the front panel of other vis by using a command line argument:
myapp.exe "myvi.vi
The startup vi still opens and runs, and the vi "myvi.vi" opens its front panel as well. That was before LV2009.
Since I upgraded from LV8.5 to LV2009, my shortcuts do not seem to work anymore. I also tried using a longer path with the new LV2009 exe structure:
myapp.exe "subdirectory\myvi.vi" since the vi is in a subdirectory. It does not work either.
1-How can I open a vi when launching a build application, like it was possible before LV2009
2-How can I (Why can I not) use the File/Open... menu item of a front panel window to open a vi that resides in side the build executable?
Thanks for any help.

Thanks Norbert for (incredibly) fast reply.
Well: in the advanced page of the build specification, we still see
the option "pass all command line arguments to application". If
disabled, only the arguments after "--" (two hyphen) are passed to the application
itself (according to the help for this dialog window). So I assume that the arguments before the two hyphens are interpreted by the runtime engine. In previous versions of LV putting a vi path (inside or outside of the exe) would open its front panel - even though doing a quick search I could not find documentation about this feature...
Is there any documentation about which arguments are
accepted by the runtime engine when the mentioned option is disabled?
Can we not give a vi that should open (anymore)?
Baptiste

How to install an older instrument driver (GPIB) LV2009 eval, 23 days remaining!

Hi..
Still having fun (I think) here trying to "evaluate" LV2009.
I'm sort of happy with the higher level stuff, front pannels, block diagrams, flow control with error signaling etc, so now time to move on and try to talk with the real world.   The Front Panel development UI is a bit of a dog, but I'll live with that.
Anyway...
I have a Marconi 6960 RF power meter (and similar kit) I can use for this "evaluation" and have found a so called driver in the NI developer zone some(i forget)where. It's a zipfile (no problem) with 4 files in. .c .h .fp and .doc    Sadly, the .doc though documents the functions of the driver, gives me no clue as to how to install it in LV2009. It also talks about LabWINDOWS V2.0, and dates from 1997.
(As an asside, most of what I will have to do, will relate to "older" or "Legacy" GPIB or RS232 connected instrumentation, and maybe one or two USB toys. There is no choice, LV is expensive enough if we go this route. But it's not even peanuts compared to the value of some of the instrumentation it will need to work with.)
Looking arround this board, I'm not realy any the wiser as to what to do with it. (This downloaded "driver" code.) It obviously needs compiling, but with what, and then integrating in LV2009, but how?
I found a link in one sort of related message, something about a driver import wizard, but the link is blocked by some spotty IT type this end, so that is of no help.
The inbuilt help from within LV2009 is sufficiently vague, or over complicated as to be of little use too.
What I need, is a simple, put that there, do this, do that type of procedure.
Again, stumped by simple details, and this is the area I will probably be spending most of my LV life in, from what's being muttered about "upstairs" in the big boss's office earlier.
Any help appreciated.
Regards.
DJB.
Just been "diverted" onto a hardware repair job, so no hurry, for now.
OK... Who let the smoke out?

Hi Dennis.
Yes, I found that page (and many others) but the info there is sufficiently vague, or so OTT for someone who does not know their way arround the darker recesses of LV (yet) to figure out.   It tells me a lot, but it does not tell me in sufficient detail *exactly* how to install a driver that someone else has created, or for that matter, how to find out what "Drivers" are installed already.
As you or someone pointed out, that code was also written way back for another system "LabWINDOWS/CVI" (whatever that was) but it shows up when you search for "Drivers for LabVIEW". It is also listed as supported by LV7.0 and LV8.0.   Those IDN pages also do not yet (that I can see) make any mention of LV2009. Is it just me that sees this as somewhat inconsitant and confusing for a new user, when NI are pushing LV2009 at this time?
Someone is now going to tell me that reusing existing older drivers *is* straightforward, but will be vague as to exactly how.
The only "exposure" to LV we've had here in the past/present, is as users of pre-compiled tools and utilities from some of our principles. And it has to be said, all of them are without exception, extreemly buggy, so much so, I personally wouldnt say they were fit for even internal Beta testing, as they don't handle "unexpected events" at all well. And some of these utilities could if they screw up, seriously damage hardware in some instances.
We've also found many many times, that anything using "VISA" IO drivers (that word again) is almost garanteed to be troublesome to get or keep working, especialy as one lab/workshop PC might have tools and programs from several vendors on it, and they must all work indipendantly when needed (not at the same time!) without interference from other vendors code or preferences. For some reason, VISA seems to make that all but imposible.
We have a situation at the moment, where we suspect a "Clash of the VISA's" as we can't reproduce what a customer has reported in the way of bad behaviour of a semi automated test system, but we see other errors relating to the serial IO used, throwing up internal LV runtime error messages, and blank spaces where the *Real meaningfull* comments should be. It's all pre-compiled code, so we have no way of supporting or debugging it, but try tell the end user that, who's test facility is now at a standstill, untill I can call the East coast USA later today (from the UK) not that I expect a constructive reply till sometime tomorrow, at best. By then, there'll be Director to Director phone call's going on!
I've also just been informed, that the workshop PC in question, will not now run something else we need, since we earlier installed the program the user is using (made by the instrument vendor) and all it's baggage, so yet another "Fixit" re-install of VISA (this time from Agilent) is needed to complete another job, and that in turn will break something else. It's a nightmare!
Sorry, but in my book, VISA is a no go for "Serious" multi vendor use. It's too fragile. In our industry (EMC and product safety testing) "Legacy" GPIB rules, almost without oposition. USB and LAN connections may be alternatives where the instrument supports them. With some true RS232 point to point low speed dedicated links where needed (often via passively powered fibre optic convertors too) for some measuring instruments.
But, at this time, all I want to do, is talk/control a simple existing GPIB instrument (a MI 6960, that I know all too well) and I thought (wrongly as it turns out) that I had found a needed "Driver".   If I have to create one from new, I will, one way or another.   But it makes a mockery of the so often quoted aspect of LabVIEW, being quick to construct and deploy a test/trial/control system etc, with an existing vast library of tried and tested instrument/device drivers. From what I see so far, it's anything but, as it's in the same ball park as all the other RAD IDE's etc (Even Delphi!) in that respect. The devil is in the detail, and if that detail as often does not exist, it's a task and a half to create it, and get it right.
Sorry if I ruffle any feathers, but I've been arround RF test & instrumentation systems at the hardware and software level for more years (decades) than I care to admit. Each and every time someone comes up with a "better" way to do something (usualy involving even more computing power!) It's anything but quick and easy, and the end result is in all honesty, not realy different to how it was done, before "enforced newness" was applied.
Regards to All, I've still got the day job to do, so sadly I can't sit in front of this and mess with software all day. Much as I need to, and often would preffer to!
DJB.
OK... Who let the smoke out?

LV2009: opening and extensively editing a v8.6 VI, saving, then error code 3

My question is about this known "Error code 3" bug that surfaces when trying to load a vi originally created in LV8.6 then saved and reloaded in LV2009. There is a suggested workaround but it doesnt seem to help me.
Using LV2009 I have extensively modified a vi that was created in LV8.6 - I saved it - and now I am trying to reload it but I am faced with Error code 3. Is there any way at all I can somehow open up the wire diagram at least?
Thanks,
TZ

It is really offended..
I get the same error message, and cannot open it.
Sounds like ... euh... not so good news I'm trying to put it mildly..
See error message below:
Message Edited by Ray.R on 10-08-2009 06:23 PM
Attachments:
badNews.PNG ‏7 KB

How to properly convert from LV2009f3 to LV8.5.1

Hello,
I have a fairly large project for an AOI which was initially developed in LV8.2 and later ported up to v8.5.
The project has a Windows and an FPGA target and relies heavily on NI Vision and IMAQ for the inspection parts of the application.
I recently decided to jump to LV 2009f3 for the new generation of the machines. I added a lot of functionality and minor bug fixes and prepared the code to work on various generations of the machine by using Conditional Diagram Disable structures and Conditional Disable Symbols.
The problem is that I need to go back to v8.5 to compile the executable and make sure that it will work on the older systems with LV and Vision 8.5 runtimes.
First I tried to save the entire project to version 8.5 but failed after multiple attempts: I always get a 'Memory Full' error with the same VI, which is the first in the project that accesses Vision functions. When I save the projecto to version 8.6 this error doesn't occur.
I concluded that this first situation is related to saving from 2009 to 8.5 when you use Vision functions.
I was able to get to version 8.5 by saving the project from version 8.6 to 8.5. The fact that you need an intermediate step is apparently well known in the forums as a bug in LV2009.
But my real problems are starting now. I currently have all the files saved as version 8.5. NOTE: the project could not be saved, but I managed to recover a version 8.5 project from my old code and used that, because the file structures were kept intact.
My current issues are with the VI's that call Vision and FPGA functions/nodes. They will ALWAYS crash: the vision related VI's crash during loading with the infamous 'Memory Full' error, while the FPGA related VI's crash during loading with the 'FPSANE.CPP' error. The 'Memory Full' error is related to nivision.dll.
I'm unable to open the VI's so I'm not sure what to do now.
Is there any way to "properly" save such a large project from 2009 to LV8.5? What toolkits and/or picture versions should I choose when LV asks me during the 'save for previous' operation? Has anyone experienced the same issues? How did you solve them?
Please help me. I don't know what to do.
On a side note, the VI's for the FPGA target opened without any trouble and I was able to compile the VI's into a bitfile without any hassle. Why so many problems with the Host target VI's?
Regards,
Habil Silva
TESTWISE
Portugal

Hi James,
Thank you for your reply.
Regarding your suggestion, I've been trying just that. I have a dual boot on my machine with Win7 + LV 2009f3 and WinXP + LV 8.5.1
Inside Win7 I have a WinXP virtual machine that runs LV 8.6. So in fact it's just like I used 3 different machines to do the porting, so that should not be the issue.
I have also created a virtual machine from the original WinXP + LV 2009 installation on the AOI machine to be able to continue developing on my laptop without having the typical file paths and add-on/driver version issues that one usually has in these situations. So I'm all set regarding this.
I'm only having these issues because I want to go back to LV 8.5.1 to do maintenance on an older machine.
Another valuable piece of information is that the VI are not really corrupted. They will open fine in LV 8.6 or 2009. Only not in 8.5.1...
What I'm going to try now is to open the project in a clean install of LV 8.5.1 but without the Vision and FPGA modules installed.
Maybe this way instead of the before mentioned errors and crashes, LV will only complain about missing VI and CTLs.
This will take some time so in the meantime I really appreciate more help.
Best regards,
Habil
TESTWISE

Traditional DAQ on LV2009?

Hi,
after doing an installation of LV2009 and it's DeviceDrivers I missed the traditional DAQ functions... Even trying to re-install (or update) the traditionalDAQ didn't work.
So:
Is TradDAQ support dropped starting from LV2009? I couldn't find information on this in the upgrade notes...
Possible workaround:
Described here: Working in the opposite direction as described I copied the files from my LV8.6 to the LV2009 folder...
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome
Solved!
Go to Solution.

Hi Patrick,
thanks for the link. It gives the same information as the link in my question, but focused on error description...
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

Imaqdx session control

I am using a IMAQdx session control to select on of two cameras in my system
but the control does not show the drop down list of cameras although correctly configured and visible in MAX.
I am using LV8.6.1. and ImaqDx 3.8 under WIN XP.
Does anyone knows the reason for that behavior?
Thanks.

Sorry for my late response.
Here is the screenshot. Both cameras (cam0 / cam5) are listed under IMAQdx.
Regards Ralph

IMAQdx datatypes in LV8.2 & LV2009

Similar Messages

Maybe you are looking for