Louis Manfredi

QUOTE (alfa @ Jul 17 2008, 01:49 AM) -same mystical forces as are at work in professional wrestling, I think. Best, Louis

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

QUOTE (alfa @ Jul 16 2008, 04:34 AM) Not sure, but what does it have to do with Chocolate? Louis

Acrophobia, me too. Even though sometimes I have to climb towers for work, this thing gave me the creeps. At least the towers I climb are usually mostly all there. Louis

QUOTE (Yair @ Jul 12 2008, 03:52 PM) 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. Louis

QUOTE (crelf @ Jul 1 2008, 08:55 PM) 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

QUOTE (Jim Kring @ May 27 2008, 02:42 PM) Excellent article Jim, thanks. Louis

QUOTE (ned @ May 8 2008, 09:23 AM) --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

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

QUOTE (xcgeek @ Mar 27 2008, 01:29 AM) 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

Gotta wonder about the relatives. If the guy was with it enough to build the robot, did he really need to go into a nursing home?

QUOTE (professor_rumsdiegeige @ Mar 20 2008, 09:24 AM) 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

QUOTE (pallen @ Mar 18 2008, 02:46 PM) 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

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

Hi Malkowski: Welcome to LAVA, Hope you find it useful. I seem to recall participating in traffic on this topic before, might want to search on CRC through the old posts. Best Regards, Louis

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

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

Hi Kabanga: Welcome to LAVA, Hope you enjoy it and find it as useful as I do! Louis

Hi Tim: Have you tried SnagIt? (http://www.techsmith.com/) Not completely free, but inexpensive & has a free trial & I've been happy with it. Best, Louis

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: 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

QUOTE(David Boyd @ Jan 10 2008, 10:15 PM) 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

Hi Folks: Thanks to all, this gives me a good starting point. Louis

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

QUOTE(Yen @ Jan 9 2008, 03:04 PM) ... Yeah but most of them seem to have lost their appetite pretty much... at least in my timeline...

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