Jump to content

Louis Manfredi

Members
  • Posts

    274
  • Joined

  • Last visited

Posts posted by Louis Manfredi

  1. Hi Folks:

    I'm trying to do some fairly straightforward communication with the PXI 6534, although there are some somewhat subtle issues:

    * external Clock

    * repetitive, but not continuous operation.

    * simultaneous triggering of output with input from a PXI 6133, and (at other times) triggering of input with output from a PXI 6733.

    At this point, I'm not looking for help on any of the specifics, but hoping to find someone who has been down the 6534 path ahead of me that might be able to make suggestions on where to get the information I need to work things out for myself.

    I find the DAXmx manual for this card more than a little cryptic. I'm starting to read the Traditional NiDAQ, which seems much more comprehensible, but I'm not sure the degree to which what I learn from that will help me with DaqMX, or alternatively whether I can use traditional NiDAQ to control the 6733 without rewriting all the code for my analog boards, which will share trigger lines with the 6534.

    I also haven't yet found a good narrative description of how to deal with sharing of trigger lines between stuff on the PXi rack.

    I'm taking a look at some of the links in this thoughtful & helpful post by Neville in an old thread:

    Neville's Post

    but if anyone else has suggestions I'll be very grateful.

    Thanks & Best Regards, Louis

  2. QUOTE (Yair @ Jul 12 2008, 03:52 PM)

    By the way, am I the only one who finds bread with chocolate chips to be a weird concept? Isn't that what you have cakes for?

    No, I found the idea weird too, until I tried a recipe. For those of us that Really like chocolate, why mess it up with all the sugar and other unhealthy stuff that goes into a cake. Just good healthy wheat bread-- With a lot of bittersweet chocolate. :wub:

    Louis

  3. QUOTE (crelf @ Jul 1 2008, 08:55 PM)

    Noise (in this context, at least) isn't always a bad thing - it's amazing what I've learned from posts that had strayed from the original thread title... (that's what tags are for :) )

    I agree completely with Crelf on this... Very often the greater tragedy is not that the original thread has been hijacked, but that the thread title doesn't reflect the newly evolved topic of the thread. And I suppose that tags can be used to fix that problem.

    Louis

  4. QUOTE (ned @ May 8 2008, 09:23 AM)

    Have you looked at http://www.copleymotion.com' rel='nofollow' target="_blank">Copley Motion? They make several stepper motor controls with a CAN interface; you could control it using a CAN card and the FPGA in an NI cRIO. I'm not sure if this would fall in your definition of "cost efficient" since a cRIO isn't inexpensive, and writing code for the CANOpen protocol may be time consuming. Copley does provides libraries and LabVIEW examples but they rely on ActiveX and won't run on a cRIO.

    --I was going to suggest the Copley motion gadgets. Not too expensive. They can be controlled through a serial port, using LabVIEW, using Copley's own setup application, whatever other programming method, perhaps even just a terminal emulator. For simple single-axis or multi-axis non-sychronized work, no need for cRIO or the CAN interface. If your laptop or computer doesn't have a built-in serial port, get a good one from a reliable manufacturer. (eg: NI) In my experience with the Copley gear there's a little learning curve, briefly steep with a good serial card, but likely to stay steep for some time with cheap serial card.

    Best, Louis

    Edit: purely formatting

  5. Probably an old technique which isn't compatible with latest versions of LabVIEW, but...

    Years ago I had an application where I needed to send a trigger message out on a number of serial ports as near to simultaneously as possible. I did this by sending the last character of the trigger message using direct i/o write to the uart registers one after another in a tight loop. I found that by putting routine which did this port i/o at subroutine level it was less likely (but still happened rarely) that the os took over and did time-consuming routine housekeeping in the middle of sending the message to the various ports.

    Not even sure if you can embed port i/o in subroutine vi's anymore, so this technique from the past may be nothing more than a historical footnote to the current topic, but FWIW, that is the only time I've used subroutine priority with any useful success.

    Best Regards, Louis

    Edit: minor typo

  6. QUOTE (xcgeek @ Mar 27 2008, 01:29 AM)

    The hardware controller hasn't been purchased yet, just the motors and sensors so I think this means if I'm going with LabView I should get a NI compliant controller?

    Welcome to LAVA-- You've started in the right spot.

    Definitely better to go for LabVIEW compliant controller, something that already has LabVIEW drivers ready for it. (But that doesn't necessarily mean an NI controller.)

    I've had good luck with stepper motor controllers from Copley Controls-- For a variety of reasons I ended up talking to my controllers through a rs232 port, homebrew drivers, but I think they also can be controlled with through a CAN network using pre-made drivers. Lots of other options from other manufacturers too-- don't feel locked to the NI motor controllers, just from reading the specs, they seem really good, but they might be more than you need and they cost accordingly.

    Best Regards, Louis

  7. QUOTE (professor_rumsdiegeige @ Mar 20 2008, 09:24 AM)

    Hi!

    Is there a built-in function in Labview to extract every n-th element out of a one-dimensional array?

    If not, how would you create a fast (!) replacement?

    Thanx in advance.

    Index array would work, with some programming, but much more straightforward is Decimate 1D array for what you want to do, same menu...

    Best Regards, Louis

  8. QUOTE (pallen @ Mar 18 2008, 02:46 PM)

    Maybe it's just me, or my limited customer base; But I've never really had a problem with LabVIEW applications looking like LabVIEW applications.

    Me Niether, In most cases my work is for one-off or a few-off systems, for use by engineers who know the app. is written in LabVIEW, who might even know how to code LabVIEW themselves... No harm, that I can see, if it looks like LabVIEW, so long as it responds in relatively predictable and graceful ways to the user's attempt to control it.

    Best, Louis

  9. I had Just the opposite problem a number of years back--

    I was field testing wind turbines using a MAC based LabVIEW DAS system in the back of a Box Van out in the field. In the shop the DAS worked fine, In the field on calm days, the DAS worked fine. When the wind was blowing to beat the band, and when I really needed the DAS to keep up with the data, it quickly got further and further behind until buffers overflowed...

    Evenually figured out that the Mac was getting all in a tizzy servicing mouse move interrupts because the truck was shaking enough in the wind that the mouse was jiggling on the desk. (Or, to be more precise, the desk was jiggling under the mouse.) The fix was simple, from time to time I still find myself following the old habit, and turning the mouse upside down when I'm not using it.

    Regards, Louis

  10. Hi Rtn1:

    Coming in late on this topic, but would like to put in my 2 cents...

    I've done some testing for a company that brewed its own IGBT based PWM variable speed motor controllers-- at power ratings well above what you are talking about but still your application is somewhat high power. I'm not totally clear on the finer points of designing these circuits, but I do know a bit about testing them and it is an activity that definitely requires safety glasses, ear protection and lots of time and money... You usually can't think of them as a simple on-off switch, but have to briefly run them in linear mode during the switching transitions. Switch them too fast and they make really nasty broadband electrical noise, which might crash the electronics controlling them, or make voltage spikes that can blow up whatever you are controlling. Switch them too slow, and they overheat and explode.

    If you're working towards something that you are going to build by the hundreds, you might consider brewing your own-- find someone with experience in the power electronics field and put them on the payroll. If you only want to build a few of whatever you are building, you are better off buying something ready-made. There are a number of companies out there-- Trace Inverters now owns the rights to the work I was involved with years ago. Copley Controls makes some nice motor controllers which interface nicely with LabVIEW which I've used recently-- and I think they also make other types of PWM power supplies. Lots of other companys, I think even NI markets motor drives, which might be adapted to your needs.

    Best luck-- If you can't buy the ready made, at least buy the safety glasses.

    Best Regards, Louis

  11. Hi CTITech:

    Welcome to the LAVA Forum. There's probably someone here who can help you out with your problem...

    At least I've found that to be the case with many of my own problems.

    It will be much easier for folks to help you if you can post the vis for the work you've done so far, describe the hardware you are working with, and generally document what you've tried already... That way the gurus will be able to help you out most efficiently. :beer:

    Good luck & best Regards, Louis

  12. Hi Folks:

    I seem to remember reading something about this somewhere before, but I can't find the reference, so I'll open it as a new topic...

    I have an old vi from LV 8.2 which had a case structure with a constant wired to it to comment out a section of code. With the beginning of a new project, I transitioned to LV 8.5. When I go to load the vi, I get the warning message:

    post-1144-1200518433.png?width=400

    fair enough, but LabVIEW crashes as it posts this message "(not responding)" in window title...

    NI suggested that I open the vi in LV 7.1, remove the case structure there, and reload, which would have worked, if as I originally thought, the vi was a 7.1 vi. Unfortunately, I had saved it as and 8.2 -- too new for my copy of 7.1, won't open on 8.5, and I let 8.2 go away in the process of upgrading to 8.5.

    A known issue, I asked support for the CAR, but there isn't one, since this is a feature, not a bug.

    Waiting for a work-around from NI support, and worst case, fortunately the vi is pretty small and won't be too hard to rewrite from scratch, but heads up if you've got lots of stuff using the old style constant-and-case-structure conditionals and you are about to upgrade.

    Best Regards, Louis

  13. QUOTE(David Boyd @ Jan 10 2008, 10:15 PM)

    ...It helps if you can have some say in how the product barcodes are encoded/formatted, so you can accept user input in arbitrary order.

    Dave

    This should be possible, The DUT won't have a barcode at all until I ask for one to be put on.

    Best Regards & Thanks, Louis

  14. Hi Folks:

    Working on a production tester, and I want to have a barcode reader to read the DUT's serial number tag.

    Does anyone have recommendations/anti-recommendations for brands or models to use with LabVIEW? USB is probably best for my PXI-based application?

    Naturally, I'm happier with one that has got a good LV driver available, all things equal.

    Thanks in Advance & Best Regards, Louis

  15. Hi Folks:

    I'm contemplating at test system which will exercise a board which has multiple channels I2S (Inter IC Sound Interface) I/O. I'm considering synthethizing the signals directly in LabVIEW and putting them out on an NI Digital I/O device. I see the example code on NI's site, and I'll start by playing with that.

    But if anyone has been down this path ahead of me, I'd be happy for any pointers, warnings or sea stories that might help me avoid pain & suffering.

    Best Regards, Louis

×
×
  • Create New...

Important Information

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