Jump to content

EricLarsen

Members
  • Posts

    88
  • Joined

  • Last visited

  • Days Won

    2

EricLarsen last won the day on June 6 2013

EricLarsen had the most liked content!

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since
    1992

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

EricLarsen's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • Conversation Starter Rare
  • Week One Done
  • One Month Later
  • One Year In Rare

Recent Badges

8

Reputation

  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 = 1.2.0.14 NI SmartBalloon = 2.0.0.2 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?
×
×
  • Create New...

Important Information

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