Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by EricLarsen

  1. Hi All, Very new to Ethercat devices, so hoping some one can tell me if I'm missing something obvious. I have a 6 axis stepper control system that uses a cRIO-9024 and 6 NI-9512 stepper controllers. The system is getting a bit old, and with NI getting out of the motion control field the customer asked me about a possible upgrade to the system. Since the old system used Softmotion and NI released Softmotion for Labview 2020, my feeling was that new controllers compatible with Softmotion should work with minimal changes to the existing software. Based on what I read Ethercat drives may be a good way to go. According to the NI website, Copley TE2 Ethercat drives are compatible and should work for our existing stepper motors. I installed all the NI Ethercat and SDI drivers and got the TE2 ESI files from the Copley website. Starting with the NI SDI Plug-In example, I can link to the new cRIO (9049), and it can apparently see the TE2 drive, but when I go to bind the Softmotion axis to the TE2 drive, it doesn't show up. I've run out of ideas, and since NI doesn't do motion anymore they couldn't help. Anybody have any suggestions?
  2. It would be interesting if anyone has a similar document specific to Labview code. NI has a style guide hanging around, it is useful but definitely not the same thing.
  3. I had almost the exact issue a few years back. I had a Windows computer that would send out a UDP packet every 100 ms to a Labview real-time PXI system. If the PXI system didn't receive a UDP packet for 5 seconds it assumed the Windows machine has failed and would go into a fail safe mode. The issue was that the Windows system was also doing some data processing, and every so often the data processing would cause the Windows box to freeze long enough interrupt the communication. The real issue is that neither Windows or Ethernet is really capable of maintaining a 100% reliable real-time communication link, especially at the relatively fast rate of 100 ms. In my case I was able to reprogram the receiving hardware with more robustness and autonomy to deal with lost packets and dropped communication links. Your first try should be to configure the I/O rack to be more robust about dropped packets if possible. Then try to disable every unused process on the Windows box, and not just the processes that may try to access the Ethernet port, but everything in the background.
  4. The ghosting goes away when the interchannel delay is 20 us. I'm in FPGA mode, so I'm only scanning the channels specified in scan list, and the grounding appears to be correct. That's why I'm wondering if I really understand the specification or if something else is wrong. I can live with a 2.4 mV error to get 250 kS/s, but 60 mV is too high and appears to be far out side of spec.
  5. I'm hoping somebody can explain what the multichannel settling time specification means. I'm using an NI 9205 in FPGA Mode, with a range of +- 10V. According to the spec. sheet, for a 4 microsecond interchannel delay, the settling time accuracy is "+- 120 ppm of full-scale step, +- 8 LSB". If I have a 5 volt signal before a 0 volt signal in the scan list, what level of ghosting would I except to see on the 0 volt channel? According to my probably wrong calculation, for a +-10 volt range, 120 ppm should be about 2.4 mV. But I'm seeing about 60 mV ghosting instead. Either I'm not understanding the specification, or something else is wrong. Anybody have any ideas?
  6. I'm finally getting around to installing this after seeing your NI Week presentation (which was really good BTW). The dependencies for GPower Error and NI SmartBalloon are GPower Error & Warning = NI SmartBalloon = There are more current versions of both libraries out and VIPM wants me to downgrade. Is there are reason these dependencies are fixed or could this be modified to allow the current versions?
  7. Just an FYI for the future, in the Labview examples there is a VI called Extract Numbers with Match Pattern.vi. Very similar to MikaelH's code and really useful.
  8. I've got a bit of an unusual situation here. A customer has an existing cRIO-9036 running real time Linux. They also have a USB-6366 acquiring some high speed signals for another system. They would like to interface the high speed signals to the crio system. They've asked if it's possible to connect the USB-6366 to the cRio. The crio system recognizes the USB-6366 as a USB RAW device. So the question is it possible to control the USB-6366 using RAW communication? I've got no experience in this area and haven't been able to find any documentation on this. The application is pretty simple, just wait for a trigger, store some analog data, then download it to the crio for processing. Ultimately the correct solution is probably to buy a couple NI-9775 modules, but for bureaucratic reasons this isn't possible now.
  9. Something like that ..... Can you recommend a device that can do that? None of the thermocouple signal conditioners I can find can come to anywhere near that speed. They typically operate around 150-400ms.
  10. We got a process which has very rapid heat up rates (~10,000 C/sec). We are experimenting with small type R TC wires to measure this process. Ideally we are looking for 1000 Hz readings on the TCs. This is well outside the rate of standard TC DAQ hardware. To add to the fun, we'll probably have very long TC wire runs (100-200 feet). We are limited to TCs instead of non-contact measurement due to physical constraints. Right now I'm using a cRio system with an NI-9205 for measurement. I've got the TC wired in differential mode with 50 kOhm bias resistors. I've also got a small thermistor IC on one of the channels for cold junction compensation. This works OK, but it's not a great solution. The TC is really susceptible to noise and other environmental conditions that affect the reading. Has anybody ever done anything like this and has some tips that might help? Ideally, I'd like to find a signal conditioner that can be placed near the process to convert to voltage to re-transmit to the DAQ. This company has something that works with type K with 1ms response rate: http://thesensorconnection.com/signal-conditioners/signal-conditioners/type-k-thermocouple-amplifier-signal-conditioner-0-5-vdc-out But I need type R. Anybody seen anything like that? Thanks!
  11. Could your instrument be echoing back the string? This is a common way for instruments to acknowledge receipt of the communication. Another possibility is you've got your TX and RX wired for loopback and you're reading back your own string.
  12. I'm developing a UI to run on a touch panel computer (NI TPC-2230 with Windows Embedded 7). I've got a bunch of Boolean controls set to Switch Until Released. The intent is for an action to happen when the user presses the button, and the action stops when the button is released. This works great in the development environment when using a mouse. But in the touch panel, pressing and holding for a certain amount of time activates a right click. This is called 'press and hold for right click' feature. I've tried to deactivate this feature by unchecking the Enable Press and Hold for Right Click in the Pen and Touch control panel, but no luck. I've done this for both the Pen Options and Touch control panel. Anybody else seen this? Is this a bug, or is there another way to disable this feature?
  13. Just an FYI, there is a better version of this vi from MGI called Change Detector.vi. It operates the same way, but has a drop down polymorphic selector that specifies whether the first call should return a TRUE for FALSE. Brilliant solution to the indeterminate first call issue of the OpenG vi.
  14. What you're looking for is called an ADSR (attack,decay, sustain, release) envelope calculation. Pretty standard stuff in the audio world. Lot's of discussions out there about how to do this. The Sound and Vibration tool kit from NI might even contain this. Or, check out: http://cnx.org/contents/18005ea2-b457-42c1-89c9-79ed1d57b73f@3/Musical-Signal-Processing-with
  15. I've got a stepper motor application that due to cabling limitations is perfect for encoderless stall detection, such as on the NI-P70360. Has anybody used this feature and has some insight they could share?
  16. Darin, you're a genius. I was barking up the wrong tree. Error 7 is a file not found error, which often seems like one of those generic error codes that's thrown out when nothing else will do. But no, in this case the error means exactly what it says, it couldn't find the library specified on the diagram. Problem fixed!
  17. MoveBlock would work if you knew the string length in advance. I don't think you could use it for a variable length string. The xnode is supposed to have some internal magic that handles strings, and it does work. Just not in a compiled executable. Sounds promising, but it doesn't appear to work. Labview interprets this as a 3 or 4 byte gibberish string. I'm trying to wrap my head around why this is.
  18. I've got a 3rd party DLL I call from within my application. One of the functions returns a pointer to a variable length null terminated string. I use the mysterious GetValueByPointer.xnode to dereference the string and return it's value. This works great from within the Labview development environment. I'm using 2013Sp1. But when I compile the application into an executable, the xnode returns an error 7. It appears the DLL is returning a valid pointer, but the xnode can't dereference it. My hunch is that the pointer is crossing some kind of protected boundary, but I don't know for sure. I suppose I could write a wrapper around the DLL call, but I really don't want to have to do that if there is a simple workaround. Any ideas?
  19. I've used the State Machine Template quite extensively, and even modified it to fit the apps I like to write. I've added the following features to the template. They are really unrelated to the State Machine processing, but more UI related. 1. Create/Open an .ini file in the same directory as the Top Level vi or executable. Could be the same as the .ini created by an executable, but not necessarily. 2. On exit, store the window position of the top level vi in the .ini file. On startup, restore the window to that position. This also includes monitor number for multi-monitor systems. 3. Use MGI Save Front Panel Data.vi and MGI Resore Front Panel Data.vi to remember control values between runs. These values are also stored in the .ini file. Basic stuff, but nice additions to most applications.
  20. Check out colored lights and lens filters as well. Narrow band filters matched to light sources are a great way to eliminate ambient variations. Consistent, repeatable lighting is the key to any vision application. Edit: Google "machine vision lighting" for dozens of companies who specialize in just the lighting you're looking for.
  21. Yeah, I did, both after upgrading to LV2013 and after downgrading back to LV2012. I had built the applicaiton lots of times under LV2012 without seeing this error. When I downgraded back to 2012 I did it by restoring working code from the source code control repository. But in the process something got snoggered up and the error survived the downgrade. It's way above my pay grade to try and figure out how that happened.
  22. This topic has come up a few times, mainly http://lavag.org/topic/13990-1502-error/?hl=1502 and http://lavag.org/topic/12461-strange-error-in-application-generating/?hl=1502. I just got hit with this issue today and will post what I found in case it will help somebody else. I recently upgraded to LV2013, and converted a large project I'm working on. Upon attempting to compile the executable, I was hit with the 1502 error with a particular VI. This had not ever happened with 2012, and the offending VI had no errors and ran fine in the development environment. Like others had reported, enabling debugging or disabling "Remove unused members of project libaries" in the build specification allowed the file to compile correctly. I figured this was some problem in LV2013, so I back converted to LV2012 and tried to recompile. Got the 1502 error again. After removing my fist from the monitor, I started to take a closer look at the offending VI. The offending VI had a subvi where I had inadvertently left a case structure with a constant wired to it. Inside of the unexecuted case were some unused LV Analysis Vis. For some reason, these were causing a problem in the compile. After removing the useless case structure and the unused VIs, everything worked fine. In one of the threads someone had mentioned broken code inside a diagram disabled structure causing problems, but I've never seen anyone mention working code inside of an unexecuted case statement. Hopefully this will help somebody who's having the same problem.
  23. I busted out my 30 year old copy of Numerical Recipes and programmed up a quick 2D bilinear routine that works pretty well. I got the resample time down to ~300 ms. Still not as good as the IMAQ function, but good enough. I had looked at the built in 2D interpolate routine in the past, and for reasons I can't remember I'd rejected it. I took another look at it today and didn't get very good results (~15s). It does some data tweaking and massaging that slows it down. But the core interpolation code looks exactly like the Numerical Recipes code, so I doubt it can do much better than mine.
  24. I've got an application that is processing some fairly large images. They are typically 4800x1280 pixels, 32 bit images. As part of the processing, I resample the image to adjust the aspect ratio. The IMAQ Resample (bi-linear option) function is fast at this, typically around 50-60 ms on my development computer. Unfortunately, this application is going to be distributed to multiple customer sites, and the IMAQ Resample is part of the Vision Development Module, which requires a run-time license for each client computer. That's not acceptable to our customer, especially since resampling is the only Vision Development function I use, the rest are custom fuctions. To get around this I wrote my own solution in G. It uses the Resample Waveform.vi function to do a row-by-row, then colum-by-column resample. It works, but it's fairly slow, around 3-4 seconds (sometimes up to 10s, depending on what mood my computer is in). Not bad, but I'd like to do better. Admittedly I haven't tried to optimize it yet, it's not a high priority. So before I dive into this, has anybody got some code or link to an efficent algorithm they would be willing to share that can do this?
  25. Yeah, it looks like you're right. Thinking about it a little more, when I create an installer there is more than just an exe. There's configuration files, 3rd party dlls, examples, etc. It makes more sense to keep track of one ProductVersion number that cross-references what versions of all the installed files were included. I think I'll head down that path. Thanks!
  • Create New...

Important Information

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