Louis Manfredi

Hi D: If you're using DAQMX try using the "DAQmx Reset Device.vi" See the image below, which works for me on a compact DAQ rack. (Note that I not only reset the rack, but all the modules too.) Is this the easiest approach? does the order Matter? Do I have to wait a full second between each reset? Don't know, but it works. I do know that sending the resets one after another, without the waits, causes a crash. resetting the rack does not seem to reset all the modules. Hope this helps, be happy if someone had more definitive advice, the manual & help system seemed rather sketchy on the subject. Best Regards, Louis

Hi Peter, Good to hear from you. Welcome to LAVA! Yes. (We'll assume I'm at least 'advanced' enough to weigh in here. ) So far I've used them exclusively as a help tool to give me a code example of something new to me. -- For this purpose, they are very convenient, both easy to access and easy to configure as examples close to what I really want to do. So far, every time I've used them I've replaced them with brand new code written from scratch. Often simply cutting and pasting bits from the express vi into my new vi. I like my code to be less cluttered with never-used cases and a little more clearly organized and structured than what you end up with from the express vis. Aside from the aesthetics of the code, it is easier to copy and paste the parts I need than to figure out how much all the rest of the stuff is costing me in terms of memory and execution efficiency. Best Regards, Louis

Hi Steve: Welcome to LAVA... might be easier to help if you included your code, but I think I can make some suggestions without seeing exactly what you have done. The message box ties up the thread that it is in until the user acknowledges it. If the message box comes up before the motor is shut off, then (as you've found out) the motor keeps running... Since you're a beginner, probably don't want to get into discussions of putting the motor control in a separate thread.... :!: Although if there are risks of damage to life or property involved in failure to properly control the motor it's control should definitely be in a separate thread-- indeed, in separate non-windows-os computer, such as a LV realtime system. :!: So, assuming the consequeces of a crash are not drastic, and working with a single thread, what you need to do is shut the motor off before telling the user why it shut off. At least three ways of doing this: 1. Rather than have a dialog box, have a boolean indicator on the front panel show the state of the limit switches. (Similar to the reporting means I use for a project I'm working on now with motor control.) 2. Within each of your two case structures, insert a sequence structure. Shut the motor off in the first frame, then post the message in the second. (Quick & dirty, simple mod to the program you've already got.) 3. Rewrite your program as a state machine, go first to the shutdown motor state, then to the post message state. (Quite a lot of learning for a beginner, but a very good programming architecture model, well suited to LabView & for that matter many other programming languages. Overkill for your current project, but a good investment in your knowledge for future programs -- even perhaps future versions of your current program--- which might be more complex. If you've got the time, search this forum on "state machine," there is a lot of traffic. Even if you fix the dialog box problem, there is a risk that Windows will wander off to do some general housekeeping while the motor is running (leaving the pot on the stove?) so if there's a risk to life or property if your motor drive crashes its limit switches, hard wire them or get a real-time motor controller. Best Regards, Louis

Hi Sandeep: I can't look at your code, because I'm running version 7.1.1 now, but perhaps you have put the DAQmx initialization inside the loop? If you try to initialize something using the same resources (a/d hardware) inside a loop you might get the message you report. Best approach is to put the initialization outside the loop, do the acquisition repetitively inside the loop, and then close the task & release the resources when you are done, outside the loop. wire the Task refnum and the error cluster from the initialization, through the loop, and back out to the close vi using shift registers. Hope this helps... Louis

Hi Raz: Try shorting the unused inputs. Very high input impedance on the inputs, a little bit of capacitive coupling between the different channels in the multiplexor, and bingo, your signal shows up as noise on the unused channels. Even if it doesn't cause any problems, a good idea to short the unused channels. best luck, Louis

Hi Sam: -- I did it that way on my first pass of the program I mentioned, and it crashed after 10 packets of data. So I changed my program to only do TCP Close connection when it was completely done. After that, it would only crash after ten runs of my program. -- To be honest, can't recall exactly which error I get when this happens (don't have the client's hardware here to try) might well have been an error 65 rather than an error 61. -- As I said, not at all sure my experience is at all relevant to your problem, but it does sound at least a little similar. Best Regards, Louis

Hi Sam: Welcome to the forum! I've had a slightly similar problem communicating with a proprietary instrument over TCP. My client's instrument uses a postage-stamp size "web widget" purchased off-the-shelf from another vendor to handle all his TCP traffic. The firmware for that widget seems to have a bug-- If my Labview program opens a connection to the widget ten times, it will crash on the eleventh connection with a TCP error. Seems that the widget can only have ten tcp processes open at once, which shouldn't be a problem, except that when my program sends the message to close the TCP session, the widget ignores the message and leaves the session open. Cycling power to the widget is an effective work-around. Perhaps you've got something similar going on? Has the printer firmware changed-- either because of a hardware change, because of a firmware update which you know about, or perhaps even a firmware update that happened automatically behind your back? (Not to be paranoid, but if something is connected to the 'net, and keeps its firmware in flash, it is possible that the manufacturer updated the firmware without telling you....) Not at all sure my experience is at all relevant to your problem, but for what its worth.... Best Regards, Louis

Hi Salvai: Welcome to the forum! Do you know what the sampling rate of your system is? This might provide some clues about the apparent noise problem. Any information you can provide about the hardware you are using, and copies of your collection and analysis program will also help us to help you. Best Regards, Louis

Nifty, I want one.

Hi Vyresince: You might want to consider writing the data as comma separated values in a printable ASCII file-- That this isn't quite as efficient of disk storage as storing directly as a singles, or even as a doubles, but it often saves so much confusion that it is worth it, especially since disk space is so cheap these days. For huge quantities of data, or other real reasons forcing compact data storage, I've found that PKZip will compress a printable ASCII file down to about the size of the same data stored in packed format. (Sometimes PKZip even does a little better if there are a lot of repeated or similar values in the data.) This assumes that your downstream analysis tools can accept printable ASCII. And, more important, that these tools can internally represent the data they get in better than single precision-- if not, it doesn't much matter how the data gets to them. Another approach, if the downstream analysis tools can't work with the raw data in acceptable precision-- Perhaps the data consists of small variations from a relatively larger mean value? If so you can subtract that mean value from within LabView, while the data is still double, then save the data as single. By getting rid of the mean, you'll effectively increase the accuracy of the data after conversion to sgl. (A final approach might be to get downstream analysis tools that work with doubles. Seems hard to believe that this wouldn't be a better approach, but perhaps you are stuck with legacy code specific to a certain field that's hard to replace. If not there's plenty of really good packages out there that can work with double or even extended precision. Lucky for you, most of these packages, which can be quite costly for us civilians, are available pretty economically if you qualify for an academic license. My favorite is Igor from Wavemetrics, at one point in the dim past only available for Mac, AFAIK still available for Mac.) Best luck, hope these thoughts help, Louis

Hi Folks: Any experience out there with the cDAQ-9172, the NI-9215 and the NI -9263? I have a potential application for this gear-- of course I

Pete's absolutely right on both counts. One recent project, rather than trying to synch the A/D process to the external event, turned out to be easier to use the A/D CTC to trigger a spare ctc on my 6036 card, which in turn triggered the external event-- so I synched the external event to the A/D rather than vice-versa. In that case, it was OK for the external event to occur without real-time reference, as long as it and A/D remained in synch. Took a while to figure out how to program the CTCs, but not the worst thing I've ever done & ended up as a nice executable that the client could install on any laptop running Windows. (As I recall, never did fully understand the manual, but some of the example VI's in the LV help system made things clear enough that I was able to do what needed to be done. definitely need to hook a scope up to the counter outputs to see what happens as you learn what you are doing...) Best Luck, :thumbup: Louis

Hi Physiker: Wecome to the LAVA forum. If you're working under Windows, 2-3 ms might be as good as you can expect. To get real accurate real-time timing, you may need to go to LabView Real Time. Best Regards, Louis

Hi Knex: Welcome to the LAVA forum. Lots of different ways to get your frequency. Many kinds of FFT in the Waveform Measurements window. Tone Measurement might be the simplest for your needs. Hope this helps & Best Regards, Louis

Hi Eerc: If I understand your question, you can change the while loop termination from "Stop if True" to "Confinue if True" by right-clicking on the while loop and selecting the choice you prefer. Best Regards, Louis

Hi BSvingen: Welcome to the LAVA forum. For a long time I was convinced that there was a big overhead in calling a sub-vi in LabView. I'm not sure where I got the idea-- perhaps it was true in the early versions of the language that I started with or perhaps it was always my imagination. At any rate, presistent advice from others and my recent experience with LV suggests that sub-vi calls are very efficient, in most cases with near negligable impact on execution time relative to the same code executed inline in the calling vi. Perhaps you can tell us what are you trying to do in your sub-vis and how you've measured the impact of the call on performance? There might be a tidier solution than creating in-line code. That said, I'm sure that if anyone knows how to use scripting to generate inline code, it would be one of the contributors to this forum. Best Regards, Louis

Glad we were able to help! & glad that you made progress on your own (partly because I've been really tied up since your earlier post, partly 'cause it is the best way to learn. :thumbup: ) I'll take a look at what you ended up with when I get a chance ( BTW, Crelf is right, better to put the file here rather than on your own ftp site-- easier for folks to join the discussion, easier for others who follow you to benefit from the historical record.) Hope you learn to enjoy LabView & LAVA forum, both are wonderful tools. Best Regards, Louis

Hi Hennig: I've had the same thoughts-- If I want to generate an error, I usually simply make an error cluster constant, and edit it to show what I want. I use a case selector with the error in wired to false, and my error cluster constant wired to true. In some cases, I'll use string manipulations and bundle the string into the error cluster to (for example) identify which stepper motor had the drive fault. But how should we keep track of which error numbers we've used, and which we haven't and how do we make a summary of all the errors we've defined? It is nice if the users can refer to the error by unique number, rather than by copying the whole message to communicate with us. Also, my method always ends up giving the "This error code is undefined. No one..." message with the simple error handler-- even if the string I put in the error cluster fully describes the problem. It would be nice to be able to shut that off-- I too find the general error handler method of defining all my error codes a little awkward for my needs-- I tend to live with the "Undefined..." message rather than dealing with the issue. Sounds like something our scripting friends might have some suggestions on. I haven't got around to re-installing Open G since I went back to 7.1, but maybe there is something there? At any rate, I share your interest & feelings on the topic. Best Regards, Louis

Hi Bart: Very helpful that you provided us with a way of looking at what you've already tried-- Many new users try to get help from us without showing us what they have already tried, when they do that, we can't help them at all (and often we don't even want to try). I'm a little busy now, but since you let me see your code I can easily suggest some ideas which might help out. Your comment in the code that the file headers should not be in the loop is absolutely correct :thumbup: But, perhaps more important, the file open dialog shouldn't be inside the loop either. :!: Open the Write spreadsheet subvi which you are using and look at its diagram. Notice that every time it is called, it opens a file, writes some stuff to the file, and then closes the file. Probably what is happening it that the last time you run the loop, this file (with one data point in it)overwrites the file (also with one data point in it) which was written the second to last time you ran the loop.... What you want to do is take the insides of the write spreadsheet file and use them separately in your program. Take the parts of the Write spreadsheet vi which get the file name and open the file and put them before your loop. Then write your header, then get your data and write it to the file, then run the parts which close the file. Use the file refnum wire to control the order in which the various parts of the file writing take place so the file gets written in the correct order.-- use the way it is done inside of write spreadsheet vi as an example of how to do this. (You also want to use the error cluster wire one wire alone will control flow, but both are good to have each for their own reasons-- you need the refnum wired to make the program work, and you need the error cluster wired to help you understand why it still doesn't work. ) Rely as much as you can on the data flow control of the program-- The file refnum, or "handle" gets passed from one part of the program to the next. It forces the various parts of the program to take place in the correct order. Most-- probably all-- of the sequence structures in your code are unnecessary. Study some examples-- such as the write spreadsheet file vi itself, and this should begin to make sense to you. to get the file Refnum and error cluster in and out of the loop, right click on the edge of the loop and make a shift register. (search online help for shift register for details.) I think there may be a much easier way to do this-- I seem to recall a version of the write spreadsheet vi that includes an input for a line of column headers. In my opinion, however, there's two closely related reasons not to use it: (1) You'll learn more about LabView by doing it yourself. (2) Once you do it yourself, its easy to make more complicated files to serve your needs-- multi line headers, more than one array of data in the file, etc. There's also probably a way of using the string manipulation tools to add the header to the beginning of your data, and writing all the data and the header in one shot. Might be a little easier, but most important to understand the concepts of data flow control-- so put the energy into that first & later on, take a look at all the string manipulation tools & see how you might use them too-- they are powerful, but some are hard to learn to use. A million ways to write any program & others may have better suggestions than mine. At any rate, hope these suggestions help at least a little let us know how things work out. Best Regards, Louis

Had some problems establishing comm. with some stepper motor drivers back when I was using LV8. These problems might have been partially explained by a non-functional break command. Problem was solved after I upgraded to LV 7.1.1, but I changed a number of other things troubleshooting the problem, so I can't say for sure that a bad break command was the cause. If it does turn out however that the break command is N.F. in LV 8, that would explain a lot for me. Hope someone can give you a more definitive answer. Best regards, Louis

Hi Chris: Thanks for the suggestion. Hardware joystick would definitely the way to go, I think, if the joystick function were a central part of the application-- but its only something I use every now & then for setup, and the poor little laptop already has cables sprouting out of all sides: A serial cable going to the motor controllers, an earphone cable going to an audio amp, an ethernet cable, an a/d card cable going to a terminal box, and the power supply. Space (and clutter control) are the final frontiers at this project, so the virtual joystick is the answer in this case. Hi Bob: Your example vi is just about exactly what I wanted & roughly the approach I would have taken to do it myself. (I'll change the colors and the size, and replace the one line with two to better simulate a tapered shank of a real joystick.) I had no idea it would be that easy however. (Especially since you did it for me ) I didn't know the picture control had built in mouse services-- thought I was going to have to deal with that on my own in the context of the entire window, which would have been a hassle. Geuss I should explore some of those bells & whistles which used to be extra charge add-in features which I couldn't afford way back when. (At one point Chris' suggestion of the hardware joystick would have been cheaper than the picture control tool kit.) Sincere thanks to both for good suggestions given quickly, :worship: Louis

Hi Folks: I'm working on a system using a two axis positioning table. Mostly the system runs automatically, scanning my test sensor in a raster pattern. But I need to add manual controls for setup, calibration & the like. It would be really handy to have a virtual joystick-- something that looks like a toggle switch, but when mouse-down on it can be dragged in both axes, providing x and y inputs to the diagram proportional to x & y position. If it optionally snapped back to center on mouse up that would be even better. Has anyone made anything like this, or can anyone suggest a suitable approximation? (If not, I'll have a go at it myself & keep you posted. Best Regards, Louis

Somehow this thread all seems to me like "the peaceful use of the atom." Is it really? And if so, is it really worth the risk that it gets in the wrong hands? Just my 2 cents, Louis

Hi Meocop: Welcome to the forum. A couple of suggestions off hand-- First, look through the examples that ship with LV for multi channel input examples-- there's many. Sort of sounds to me like you are using single channel input vis twice, probably each one is trying to assign the same A/D card to two different resource handles-- One of the multichannel examples should put you on the right course. Second suggestion, would be to include the code you've tried that doesn't work in your posting-- either as the vis or even just as a screen capture of the diagram. Much easier to show us what you did wrong, than for us to try and guess. (There's so many different ways of doing things wrong-- but there's lots of us in the forum, so if you show us your code somebody in the forum has probably made the same mistake before and will be able to help you out.) Trust me, you'll come to love LV at least as much as you'll hate it. Good Luck & Best Regards, Louis

Hi Folks: Success :!: Reinstalling LV 7.1.1, After throughoughly and truely unistalling it and then manually throwing away all the fragments left behind by the uninstall process worked just fine. I suspect Kennon's suggestion that I simply delete the damaged llbs might have also worked, but I didn't want to take any chances of missing something, so I went for the thourough route instead. This has been a long, drawn out thread, so for those that might follow me, or encounter similar problems: SUMMARY: Some time after I installed 8.0 or 8.0.1 a few of the library vis used by the 7.1 app. builder (and also by some programs of my own) got recompiled and saved for version 8. I'm not sure if this was my fault, LV8's fault, or a team effort between the two of us. If I had to guess, I'd say it was a team effort. The crash messages left by the app. builder were a little cryptic, it took a while to find the damaged vis. Uninstalling LV 7.1.1 using the Windows installer, and reinstalling it from the orignial disks didn't fix the problem. (In retrospect, I should have known better-- I think this has happened to me before. The Windows uninstaller can't be trusted to really ininstall everything-- Especially stuff shared with other software that you might have on the same machine. I've been around long enough that I should have known to also check for and delete any remaining 7.1 directories and their contents. Another clue was that the program launched as 7.1.1 after the re-install, despite having reinstalled using disks labelled 7.1) Uninstalling LV7.1, using the windows utility, then manually deleting all the remaining stuff, then installing LV7.1 from disks, then installing LV 7.1.1 from the download patch file, then mass compling the LV 7.1 directory worked fine, and all my problems seem to have been solved. ('Though a sad fraction of my life has drifted by as non-billable hours.) (Parenthetical note to Jim Kring: I haven't tried again to run the Open G installer you suggested, but I bet it failed because it was calling the same damaged library vis as the NI installer. Sometime soon I'll try it, and my bet is that I'll find it works very nicely. I may also try the installer that Irene He suggested someday. Might be good to have a separate thread to discuss relative merits of these, and any other available installer builders.) So finally: THANKS :worship: Thanks to everyone who contributed suggestions. Special thanks to Kennon Cotton of NI, active on this forum, and Jennifer Ormston of NI tech support for their persistant efforts in helping the user. Most regulars on this forum know I can sometimes wax more than a little eloquent about the shortcomings and bugs of LV. Fact of the matter is, it is a terribly powerful and complex piece of software. Such software is bound to have the occasional quirk. I continue to use it because it allows me to do some pretty complex stuff pretty easily. Much as I complain, I really believe the benefits of the package far outweigh the flaws. In large part that is true because there are folks like Kennon and Jennifer at NI who answer the user's cry for help and stick with us 'till we get the answer. So to everyone, Thanks & Best Regards, Louis.