WMassey

Actually I believe he was talking about when someone presses the VI's "Abort Execution" button (the stop sign on the toolbar) and there is no event to capture that. The VI just stops dead in its tracks. It has to work this way to allow people to stop VI's that have infinite loops built into their exit cleanup routines. You can always prevent the user from accessing the abort button however. See here and here for more discussion. The attached VI (LV v7.1.1) is a simple way of trying some of this out. Download File:post-2800-1141994145.zip

I think of polls as something used for measuring opinions. When you say you are talking about documented facts and you don't use polls to measure those, just statistics (depending on what you want the result to say). Yes, it might indeed be time for a break... (And as a side note to Michael, Hey the indent worked! First chance I got to try it. Thanks! :thumbup: )

I read through the discussion over on the NI Dev-Exchange about this and it left me wondering why not have just one ever-growing topic (sort of like this one for Darren's weekly nugget) that, for every confirmed bug, consisted solely of a brief synopsis and a link to the discussion of the bug (be it on LAVA or NI). Then there would be one place people could go to see if something had been reported or not. The trick would be to keep the bug list/topic free of discussion (bug-specific discussions would need to be reserved to the bug-specific threads, whether they be on LAVA or NI). To be sure that the bug list did not get polluted with noise would probably mean that it would need to be moderated like the FAQs are here on LAVA. I understand that moderator privilege of the NI forums is not something NI wants to let non-NI people do and, in the case of a bug list, I'm not sure I'd want an NI person doing it either. Perhaps it could be setup here on LAVA? A simple pointer in the NI forums to a LAVA bug list would suffice for the people looking for reports over there.

There definitely may be better ways of doing this but I believe if, in the dynamic case, you were to make the VI in question run as a subVI to another main VI that did nothing more than call the subVI, then I think it will work.

OK, attached are the converted VI's (you'll have to add back in the DLL's and the INI's and so forth). The jump from 6.1 to 7.0 added some features to the event structure that these VI's made use of like triggering on a mouse down event and being able to pro grammatically change a front panel control and have that change picked up by the event structure (the Value (signal) property of a control). Since 6.1 didn't have these abilities, the converted VI's are broken and you will need to make adjustments to get them to run. Download File:post-2800-1141559657.zip

I never have convinced myself that LV v8 was worth it, so I cannot poke at your VIs but I've seen something like this problem in LV v7.1. What I have seen (in more than one case) is that VI "A" in dynamically invokes (as a separate process) VI "B". Both VIs share many subVIs but each one does have a few unique subVIs. Both "A" & "B" work without problems when the VIs are running under the LabVIEW development system. "A" can also start "B" without problems running under the development system. Both "A" & "B" work without problems when each is run as a standalone application. But when "A" (running as a standalone application) tries to start "B" (also running as a standalone application) then "B" will open up broken. I discovered that in this circumstance "B" thinks that some of its subVIs are missing. Once I figure out which ones those were, I added them to a commented-out section of code (LV8 handles this differently I understand) in VI "A" and after that "A" starts "B" without problems.

LabVIEW can read from 2 serial ports just fine. I've done 6 at the same time so far and I see no reason why it couldn't be 60. It wasn't clear from your message but have you ever gotten the reading of messages from COM2 to work? You do know that the way you have your main WHILE loop designed that there are two tasks that both have to complete before one itteration of the loop finishes and the next itteration of the loop starts. So it may be that something going on in the top half (COM1) of the loop could be hanging the loop causing the bottom half (COM2) to never get a chance read more than once. You might want to split this one loop into two independent loops (at least for the sake of testing). After doing that you could even drop the bottom loop into its own VI (drag all of the bottom loop's code from its block diagram onto a blank VI's empty block diagram) and that would give you an independent copy of the code that should run and display whatever appears at your COM2 port. You could then do likewise for the top loop (get it into its own VI) and you should also be able to run that one indepently against COM1 and the motion controller. If both VI's run indepently then you should be able to make them run when combined. two loops: two VIs:

Ahh that's it! I too made the assumption that it would return an error. That'll teach me to assume anything. Thanks for clearing up the mystery. :thumbup:

I would post it but even with all the motion control VIs gutted and the OpenG VIs removed it's still 122 files and about 3Mb when zipped and that is more than I'm allowed to attach to a posting here. Send me a private message (click on my user name) with your email address and I'll try sending it that way.

I recently built a LabVIEW application which would allow a group of mechanical technicians to cycle several axes of motion through whatever different positions they might choose, acquiring position data at points they specify, to check the repeatability of the system. They seemed quite pleased with it (but who wouldn't be after having to do this with individually-input positioning commands and pencil & paper). It was definitely not a beginner-level LabVIEW program but it wasn't too difficult either. It did make use of the LabVIEW state machine concept (it couldn't have been built otherwise). The operator is presented with a "listbox" that he can populate with program steps. He highlights a line in the listbox and then chooses an action to perform from an enumerated list of actions below the listbox. Depending on what action is chosen, other controls specific to that action then appear to let him specify the details of the action. After he is finished detailing one step he selects another line in the listbox and repeats the process until his "program" is finished. The LabVIEW programmer has to ensure that all possible actions that the operator might need are available in the listbox. You may want to include "repeat" as one of the actions available with arguments of which step to repeat to and how many times to repeat. Give the operator the ability to save, recall and edit the sequences he assembles. When the program is run it just steps down through the list of actions, jumping to whichever state machine state performs that action. It won't be very difficult to add new actions in the future if they are needed; it'll just mean a new item on the list of actions and a new state to handle it (and a conversion routine to convert the old saved-sequence files to work with the new data structure action). Yes it is possible using basic LabVIEW. No it is not something that comes pre-assembled. NI's "Test Stand" software may provide you with more out-of-the-box functionality in this area.

I am working on a way to synchronize and protect read/modify/write access to a functional global containing state information. I had first thought of using a common semaphore created by the functional global but used by a re-entrant read/write vi one level up in the hierarchy. I soon discovered that a lower-level vi cannot create a semaphore reference and pass it up to a higher-level vi because the semaphore reference does not survive once the vi that created it stops running (<-- never mind; not correct; the semaphore does survive as long as the top-level VI continues to run). Anyway I'm not too proud to learn new ways from others and remember having seen the example you had posted did locking and unlocking of a share block of data so I thought I'd look into it more. I did look at it and, if I understand how the lock/unlock should function, then I don't think they are providing the protection they should provide. This is how I tested. The test vi (LV v7.1.1) is attached (it makes use of subVIs found in the original example) What am I missing? Shouldn't the first lock cause the failure to occur in the second lock request rather than in the final release request. Download File:post-2800-1141066053.zip

I'm glad to hear that you were able to make this change. It makes everything so much more deterministic. You were correct in the parts you removed from the top-level VI but you also needed to enable the terminate-on-character option for the VISA. See attached VI for the corrections. I've also fixed it so that if you do get errors you can see them. Download File:post-2800-1141018911.zip

I think it's great that you have put together something of your own, that you can understand, for accomplishing what you need to get done! I certainly do not feel let down (not that you had any responsibility to "keep me up" in the first place). I'm glad that I have helped you learn a bit about LabVIEW if nothing else. I've done the EE thing (and for that matter the ME thing as well) and my son is in his sophomore year at the University of California (Berkeley) doing the EE thing as well so I know what you are going through and I have no doubt that you are a very intelligent person. I never meant to imply otherwise, if I did so. As to your questions: 1) For the "jog" function - you only want to send out a command when the state of the button TRANSITIONS from low to high or from high to low. While the button state is low or is high you don't want to send anything. So you need to know the prior state of the button and compare it to the current state and when there is a difference then you send out a single command dictated by the current button state. (BTW, your CV command may need a speed argument). 2) This would have been much easier if your microcontroller used a string terminator character after each message but you are probably getting as tired of hearing that from me as I am saying it. Anyway if the number format in the message is always exactly like you specified then you can search the collection of bytes coming in from the VISA read function for something that looks like 3 numeric digits a decimal point and 2 more digits and when that string is found, pull it out and use it. 3) This will be easy to do once you get #2 above right. The "scan from string" function will do all that you need if you feed it good values. See the attached top-level VI. And I would very much like to see any pictures you might have of your project! Download File:post-2800-1141002358.zip

Jim, The two links you referenced no longer work. Can they be fixed? TIA, Warren

I'm glad to hear that. Do you know that this too can be accomplished through the LabVIEW? You have a Jog(+) & a Jog(-) pushbuttons ("Switch Until Released" action) and when a button first transitions to a pressed/down/on state you issue a jog command (the McLennan "CV" command) and, depending on which button was pushed, you set the sign of the argument to the command either positive or negative to set the direction. When the button is released then an axis stop command is sent. I think you do have indicators in the LabVIEW already. See below. You speak of your hardware "cuts the power" to the motor. Based on my reading of the McLennan manual, if you are using their hardware to handle the limits then it shouldn't just "cut the power."From page 8 of the manual: So you can set it to either just stop stepping or else just decelerate to a stop but neither of these is "cutting the power" which I don't think you want to do with a stepper anyway because it's holding torque is greater with power applied than with power off.You need to read about and figure out how to use the soft limits that are supported by your McLennan controller. Search the PDF file on that term. This will require that the system know its correct absolute position so you will have to get the home switch operating (or the datum switch as McLennan calls it). If you want to see the status of the DATUM switch using the LabVIEW, you will need to use the "RP" command. Again this could be handled by the soft limits. If you want to add an additional set of early-warning limit switches to the system and have those tell the software to stop the motion you could indeed do that. But, if it were me, I'd use a couple of the "Read Port" inputs on the McLennan controller to get those signals into the controller which could, in turn, make them available to the LabVIEW code (again through the RP command). It may not be a good idea to hook signals from an industrial control system directly up to the parallel port of a PC. Some of that industrial-strength noise may fry your motherboard. Like I said, you've already got this indication: And this is how you would access the booleans within the main program: And, FWIW, according to the error messages (page 77 of the manual) that the McLennan will return in response to commands, it will even tell you when you are at a limit.

You are on your own as far as advice from me on using the parallel port - it's something that I have no experience with. But, if you are still thinking of bringing in the two limit switches and the home switch through the parallel port instead on through the McLennan controller where they belong, let me urge you in the strongest possible terms DO NOT DO IT! You can damage equipment or hurt people if you don't do this in the correct manner and what you proposed a few messages back is definitely the wrong way to wire in the limits! You will not "Increase your marks" if you either hurt someone or damage something. What's really bad about what you are proposing is that it has a chance of working at least some of the time and that will give you a false sense of security. It cannot be relied upon to work all the time however and there is where the problem lies. What are you going to do when you have just given the motor a jog command and it has started running and your PC (or LabVIEW) crashes? It's been known to happen and they won't be the only things crashing in this example. The motion controller is a much more reliable device in this respect (and at least, if it crashes, it will stop stepping the motor). The McLennan manual tells you how to hook up these switches to the controller and you need to follow those instructions. Later when the LabVIEW makes a request for axis status, the state of all three of these switches is already included in the data returned from the controller and you can use that for driving any front-panel indicators. DO NOT USE THE PARALLEL PORT FOR THIS PURPOSE!

First of all, you probably don't want to repost the entire system of VIs if all you changed was one of them. It's a waste of space on the LAVA server. Second, I know nothing about the communication protocol or message format of your encoder readout device but I suspect that it ("Yak at McLennan Encoder.vi") will not work since you have turned off the "Enable Termination Character" function. With that turned off, the only way that the "VISA Read" will terminate is when the "Byte Count" number of bytes have been received (which is set to some high value like 100) or when a timeout occurs. The "Yak" vi's are only meant to work with messages that have some sort of termination character. If you built this hardware then you could modify the code it is running to include some sort of termination character couldn't you? It could be any character that doesn't otherwise show up in the message. A carriage return or a line feed character are the typical terminators but it could be anything (space, tab exclamation point, ...). If you cannot change the code, then it becomes more difficult to correctly readout the device. You have to build the code so that it knows when it has a full/complete message or reading and not a random collection of numbers made up from the tail end of the preceding message and the beginning of a new message. For example, 1) if the axis was stopped and the encoder position was sitting at a value of 12345 2) the encoder device continually spits out the current reading over & over again 3) you have the VISA Read setup to terminate after 5 characters (Byte Count) are read in 4) then when you go do the VISA Read, depending on when it starts to listen to the serial link you might get any of these values returned: 12345, 23451, 34512, 45123, or 51234. The situation becomes even more confused if the axis is moving and the numbers are changing and it becomes nearly impossible to deal with if there there are not a constant number of characters in each message. If there is a fixed, known, constant delay between the encoder messages then you can play with timings of multiple VISA Reads to determine when you have one good reading but this is an inefficient way to spend your program's execution time. As far as where to add the encoder position check/display into the main program, to help make that decision you need to get a good mental picture of how the program works. To that end, why don't you build a flowchart of the main program. Keep it high level. These are the nodes I'd suggest using in the chart: Initialize System, Check Motor Status, Moving?, Disallow Timeout, Allow Timeout, Update Display, Adjust Parameter, Start Motion, Wait On Event ( containing Setup Change?, Timeout?, Move? Done?) and Shutdown. FWIW, if you have access to Microsoft's VISIO software, it will do flowcharts. Pencil & paper work well too. And on another subject, this probably will not do whatever you were trying to accomplish when you added it: The "Response" buffer just contains whatever was last read in for any axis. If you want the position for a specific axis, then you need to pull it out of the "Axis Status" array (just below it in the picture, use the index array function {with the correct index for the axis you want} followed by a Unbundle by Name for "Current Position")

The drivers (NI Serial v1.7) that shipped with the units did have their problems. This is the behavior I saw (in July, 2005): Problem Description : Using LabVIEW and a ENET-232/4 connected to a WinXP PC on a private ethernet through a hub I can establish communications and continuously talk to an instrument for as long as I want. But if I pause the exchange between the PC and the instrument for more than about a minute then the "Port 1" light(the port in use - no others used at this time) on the ENET-232/4 goes out and the Labview VISA will generate an error when an attempt is made to resume communication. I have to reinitialize the VISA serial port before I can get the "Port 1" light back and communication can be re-established. I complained to NI and they responded quickly with NI Serial v1.8 and that cleared up all the problems that I knew about and I'm running it on a system with a hyperthreading 3.2GHz Intel CPU. I just did a quick check of the NI Serial download website and see that the drivers listed there jump from 1.8 up to 3.0. I have not tried 3.0. Were the problems you were referring to fixed in the 1.7-to-1.8 change or the 1.8-to-3.0 change?

It worked just fine on my system under v7.0 when I tried it showing COM1 & COM2. It show address ASRL1::INSTR for COM1 and a blank for COM2 but that's because my COM2 is tied to a status port on a UPS and was unavailable to respond to the port query.

Take a look at this post and this one too. They both have attachments that do reads from serial ports. This post has an attachment that sends commands to and receives responses from a motor control system over a serial port. Whose motion controller are you using? What model? As far as the VI you posted is concerned, you can use a non-zero value in "Bytes at Port" to tell when to start looking for a complete VISA response but do not wire "Bytes at Port" into the VISA Read "byte count" input. Instead, wire a large (256?) constant value to the "byte count" input and setup the VISA read to terminate on a message termination character (usually a carriage return or a linefeed, whichever comes last in the message) as shown in the examples referenced above.

Well you could download and install the v7.1.1 runtime engine and then subsequently try to uninstall it again. If this is a WinXP system, is there a recent restore point you could call up? Probably not after all the recent uninstalls. Short of that, you may need to fire up RegEdit (or for more ease of use get Registry Crawler) and manually go through the system registry removing all references to all instances of anything to do with installed NI software. (backup your registry and create a system restore point first). As you find keys that refer to NI files on disk make sure that the files are removed as well. It's a painful process (been there, done that) but it will allow you a fresh start if done completely and correctly**. **Aye, there's the rub Good luck!

I don't know about either of those interfaces but I had had good experiences with National Instruments NI ENET-232/4 and it would only stand to reason that they (NI) would make an effort to make it compatible with the LabVIEW. After installation it just shows up in MAX as additional serial (COM) ports and you talk to it using the ordinary VISA serial routines. In one situation I'm using 6 ports (2 interfaces off of a hub on a private network) and it has been fast and trouble-free. I like it.

I am relieved that you were able to find and fix the problem (you did remember to fix it for both axes didn't you?) It's good that you are starting to get into this LabVIEW programming. It can be fun (or at least not boring). Since you are new at this I have attached a PDF file that shows how I have the LabVIEW options on my machine setup. You may find it useful, or you may have already figured out a setup that works well for you, in which case you should stick with it. I'm glad to have been some help to you. Feel free to pass it on. Download File:post-2800-1140668131.pdf

If you are speaking of the read buffer size ... ( "Number of Bytes to Read" input to the VISA Read function or "Max Allowed Byte Count" input on the VI I posted ) ... then there should be no problem with a 1000-byte buffer. Heck, it's a U32 number so it should be able to take a really BIG value if you wanted. How much memory do you have in your machine?