Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About CraigGraham

  • Rank
    More Active
  1. The path's being ignored anyway- the DLLs are in a seperate folder elsewhere in the PC's filesystem, but the installer shoves them all in a support folder in the same directory as the built executable, called "data" by default. We did try FTPing the original executables in- that's the reference executable I mentioned. And regarding taking an image- anyone know how? This just has RT installed. NI built the PXI controller up, and gave a multiyear warranty for it which I suspect'd be voided if I was to take the hard disk out and put it into another machine to read an image off.
  2. I've a problem with a PXI chassis running LabviewRT at a client's site. Some months ago, we got the chassis from Labview, installed necessary DLLs for a couple of non NI cards and put our app on there; it then worked fine until the client reformatted the disk and reinstalled Labview. Precisely why this happened is unclear but doesn't seem to be related to a problem with the software. We're on 8.6.1. I reformatted again and reinstalled myself, to rule out any oddities that might have occurred when the client did it. We're now in the position that although as far as I can see the software and all components are installed correctly and the app will run from the IDE, which can then disconnect leaving everythiung fine until the next reboot, I cannot deploy the app as startup. When I try, in the "Deployment Progress" window I get the message "Deploying Main PXI app (failed to deploy)" just after it says "Deploying <our PXI ID>". At the end, it says "Deployment completed with errors". A file is there, but doesn't run when rebooted. If we stick with the file that's been placed there, and attach a debugger after startup, we find that the app has loaded but that all VIs that have a dependency on any of the 3rd party DLLs are listed as being broken. These are DLLs from two different vendors for two different cards. If we place an old reference copy of the executable on there, the debugger connects, all the windows open showing the VIs *are* there but then the debugger pops up the message "Failed to connect to remote application" and everything closes again. Since the app works fine when started from development, it seems we don't have a major problem with the installation, but that there's some difference between running from the IDE and running from startup that's now giving problems. My suspicion is it's to do with DLL deployment; the IDE needs local copies of the DLLs since they're being called via the "Call DLL function" node (or whatever it's called). It then puts these copies into the "Data" subdirectory. I suspect there's then some conflict between those copies and the ones in /ni-rt/system, which have to be there because they're running the cards so have to load when the system boots and does its hardware detection. I tried removing the local copies, but then the app fails to build because it can't find them. Phoned NI and have a case ongoing, but I'm not optimistic; after a long phone conversation and the engineer going off to consult, the response email is to try reinstalling again but to reboot PXI after each component install. Which we'll have to do, but I don't think it'll get us anywhere. Does anyone know what could be going on, and how to fix it? Anyone know of a way of telling Labview that dependencies are to be met by DLLs already installed on the target and not to try sending extra copies? Or what the differences are between running from boot and running from the IDE, and getting the boot to be the same?
  3. We have to put a bid in on a project that the client has decided to use Compact RIO for. New toys they want to play with. I've not done it before so I've been playing with the FPGA module and FPGA interface in Labview 8. Actually doing FPGA code and running it on a bit of hardware set as emulated works fine, but I need to be able to communicate with a UI VI on the host PC. When I (or any of the examples) try to open a reference to the FPGA VI from the host, an error is generated to the effect that Labview can't find the hardware. Should I be able to do this on emulated hardware or is the emulation only there for playing with the FPGA code in isolation? Before it's suggested, we're not buying the hardware to play with in order to make an informed bid.
  4. QUOTE(ashishuttarwar @ Nov 26 2007, 12:20 PM) Yeah, using App Builder on the machine having set the LV execution target to cFP gives you that startup option and installs straight to cFP. As far as I can tell, though, there's no way of getting that option if you don't have the target cFP connected. There's unofficially a dev environment still installed down there that I shoved on for debugging, so for the moment I can talk him through App Builder on the phone, but if we can't officially update a cFP installation without going down with a full development system then it's a mark against using them in future. Specs and requirements change! Re using IE to go in and delete the existing exe- that'll just stop it doing anything from power on until the App Builder exe shoves the transient runtime code down. Thanks for the responses- least it seems I'm not missing something stoopid
  5. I've a distant cFP unit that needs an update to the VIs running on it. App Builder (LV7.1) has options to prompt for an RT target, so I bundled it all up into an .exe to ship to the client, who then ran it and selected the cFP unit. It downloaded without error, but following a cFP reboot the old app is still there. Is there a way to get an executable I can send to the client which permanently updates cFP in the same way as when I run App Builder on a PC local to the cFP unit and build directly to cFP? The way I've tried so far seems to be akin to targetting Labview at cFP, loading the VIs and then selecting "Exit without closing RT Engine VIs".
  6. I've a distant cFP unit that needs an update to the VIs running on it. App Builder (LV7.1) has options to prompt for an RT target, so I bundled it all up into an .exe to ship to the client, who then ran it and selected the cFP unit. It downloaded without error, but following a cFP reboot the old app is still there. Is there a way to get an executable I can send to the client which permanently updates cFP in the same way as when I run App Builder on a PC local to the cFP unit and build directly to cFP? The way I've tried so far seems to be akin to targetting Labview at cFP, loading the VIs and then selecting "Exit without closing RT Engine VIs".
  7. I've got to make some mods to a legacy VB6 app that's written using Imaq, NI-DAQ and ComponentWorks. There's no documentation about build environment. I've installed VB6, NI-DAQ, IMAQ, NI-Vision and Measurement Studio into a VM running XP and can now load the project without it bailing out due to missing .ocx files etc. However there's methods and types that are unrecognised- initially, CWIMAQBCGOptions. VB6's autocomplete does recognise "CWIMAQBCGOptions" but when I try and build/run the app I get a compile error "Can't find project or library". Google and NI's search give no hits. Anyone know what this is a component of, and what version I need to find? So far I have Imaq 3.1.1, DaqMX/NIDAQ 7.4.0, Vision 6.1.0 and Measurement Studio 6.0. It doesn't find its dependencies on loading the project on my normal work machine which has Measurement Studio 7 and recent NIDAQ and Vision so I'm assuming it's some obscure and old version that's needed.
  8. QUOTE(Neville D @ Mar 20 2007, 06:13 PM) No, could find nothing like that in MAX. I didn't have the old IMAQ on the machine so couldn't try the old examples. What it turned out to be was a register "ISO_ENABLE" inside the camera. This register gets set when calling IMAQdx Start Acquisition and overrides the single/multishot settings defined by the "configure acquisition" VI to force the camera into free running. Writing a zero to it immediately after calling start acq. gets everything working fine. This behaviour is there even when setting the camera to a non-ISO capture mode in MAX so I don't know whether it's a bug/camera dependent issue or some obscure setting I can't find, but it's a fairly painless fix.
  9. I'm playing with a firewire camera in IMAQdx, LV7.1. Yeah, not got round to updating to 8. I've done an ugly as hell test VI (that I'm not going to post in its present form) that's based around the code in "IMAQdx Snap.vi". The only functional changes are to put the Start Aquisition...Get Image...Stop Acquisition group of sub VIs inside a while loop to snap an image every time I hit a button, and to monitor and display the output of various digital lines as it's happening. What I've discovered is that the camera is actually taking 2 shots each time. Further investigation reveals that, even if I load the original "IMAQdx Snap.vi" and put a breakpoint after the "Get Image", the camera keeps triggering. The "one shot" doesn't seem to actually mean single shot. Anyone else come across this?
  10. I've got to go fix a project I'm unfamiliar with, and I'm looking through the code to get pointers. It's a PC talking to a cFP unit via the TCP VIs. There's also the data publishing stuff and direct Fieldpoint IO point reads being used at the same time. Symptoms are that after an unspecified length of time, the PC loses comms with the cFP unit. There's two places the reported error can come from- first is from a Fieldpoint network read function, second is if the TCP bit fails to establish a connection. I suspect the latter. The way this is written, the TCP stuff opens a connection, sends a few bytes, gets a few bytes back then closes the connection again- then immediately repeats in a loop. It's in a timed loop with a 50ms tick but this isn't doing anything against the larger loop execution time. This means many connections are left in TIME_WAIT, so the obvious questions are how many ephemeral ports are available for use on cFP and what the TIME_WAIT period defaults to on cFP? Anyone know? On my XP machine, Labview's only using a couple of thousand ports, making a couple of connections a second, and the TIME_WAIT period's evidently less than the 15 minutes or so it'd take to get port exhaustion but I could imagine cFP using a smaller port range to save resources.
  11. CraigGraham


    I'm revisiting a cFP project I've been away from for a year, and I no longer have access to the hardware until the few days when I go onsite to deploy an update. I want to add watchdogs to the cFP code, but can't seem to find decent info and with no cFP controller I can't play. Don't want to be implimenting new features in the deployment time. I have several loops, and ideally would like one watchdog per loop so if any loop hangs the whole thing reboots. Can I do this simply by having multiple "Watchdog Configure" nodes and wiring the watchdogIDs to whack nodes in the individual loops? I've had a play with the VIs on Windows but they do nothing, so I'm not sure that being able to code this on Windows without getting broken wires actually means anything.
  12. I did a check of this since a recent app makes a lot of use of abstracted data types for plugin modules. Converting a test cluster from a variant to data, modifying an element then converting it back to a variant takes about twice as long as when the conversions are to and from flattened strings. So aside from the implicit conversion to variant, variants no longer have any appeal to me. Would be nice to be able to define a string input to a VI as being "implicitly flatten".
  13. It's a poor substitute, but you can use ActiveX controls under Windows- either existing ones or ones you've created yourself in a different language. Before NI supplied a treeview control, for instance, I was using the standard Windows one via ActiveX. Obviously many drawbacks over a native G implimentation, but it does have uses.
  14. How long has that "prepare for reentrant execution" option been there? i.e. how long have I needlessly been messing around with VI templates?
  15. Ooo. There IS an option "--no-tty" that I thought just suppressed all output. It turns out it lets me redirect the streams to get at them from inside Labview, but when I try and do interactive stuff it tries to be too clever; gpg: Sorry, no terminal at all requested - can't get input So I think I'll call it quits for the moment. There's two alternatives- LibGCrypt on Linux that I'm going to play with, and the commercial PGP SDK that I'm looking into. Though I suspect the commercial one will be a bit too pricey and charged per deployment. Can Labview on Linux use dynamic link libraries? Might be an option if we go the LibGCrypt route, but we don't yet have LV on Linux and they seem to have stopped the Linux evaluation CD that used to be available.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.