ShaunR

I'm even worse (although I don't use a FG. Instead I use named queues) and only use strings for all my queues' data 1 VI for any queue anywhere within my code

I agree with everything Daklu has said (with the exception of efficiency but wholeheartedly with typos). Since I am firmly in the case structure camp for this stuff I would also add (in addition to my earlier posts which detail other aspects): Pros: Much smaller code base. Single point of maintenance, Better genericism (what do I mean? Discuss ). Looser coupling between messages and code (there is no code for messages). Less replication.(you don't need wizards or tools to save copying and pasting). Better portability (messages can easily be transmitted via ethernet, serial etc and interface to non-labview languages). Cons Typos (trivial) State difficult to handle (e.g. timed/timeout responses). Dynamic dispatch is a stealth case statement with handcuffs

Nope. It's a (2012) vanilla install (same in both 32 and 64 by-the-way).

You read the address then mask (and) the bit you are interested in to get that state. You will notice that the bits are 2^n so each bit represents the state of an output/input. So to get the state of "Control Contact 4", read the word at 0x026 then AND the result with 0x8. If it is greater than 0 (1), it is on; 0 it is off.

There is a broken VI in the latest version 0.3 (never seen this error before, presumably because I shy away from xnodes).

I would start with the "echo" command. Once you get that working (i.e. eliminate all the serial configurations and get something tangible back); it should be plain sailing from there.

Yup. It is a nice trick (refnum) because of the polymorphism that can be performed and it is "the right way". However. I have found that this is true only within LabVIEW and when dealing with interactions with external code, it is better (IMHO) to leave things in the native form for things like this since you only end up type casting it back to an integer to pump it into another call. I had the same sort of thoughts with the SQLite APIs SQL ref but left it as an integer in the end since every VI ended up with a type cast in and out.

The easy way would probably just expose it as a 32 bit value and if the user "must" have it, then make him deference with a moveblock (move the issue downstream). However, I'm not sure what you are asking here. If the DLL is 32 bit bit, then it can only be loaded in LV x32 (and therefore can only handle 32 bit pointers anyway). If it is a 64 bit, then that cannot be used by LV32 bit. So if the cluster uses a U64 it will be able to represent both even if it creates a "red dot" when passed to another API/DLL call which is set to pointer sized.

Well. The basics are that your PC will be a "master" on the bus (RS485 is multi-drop, meaning you can have multiple units on the same wires). You read/write to an address on the bus (the unit) and registers (memory locations) within the unit that correspond to configuration, inputs and outputs (outputs are sometimes called coils). Generally, the registers are device dependent so you will need the programming manual to identify them. However. It would be a good idea to start another thread so that we don't hijack this one.

Did you set the controller to use the Modbus protocol? Ummm. I posted a link to the NI Modbus vis which, you have now downloaded.

The controller isn't RS232. It is RS485 (according to the docs). Therefore hyperteminal or equivalent will not work. Looks like it has two modes of operation. CompoWay/F and Modbus. Modbus is an industry standard and, if you have the NI DCS module, you can set it up with the OPC server. Alternatively you can use the VIs I linked.

Nope. Still not convinced!. If they can spend oodles on POOP and trivial eye candy, then they can spend a fraction of that on standard OS event methods for the rest of us. It's not rocket science. GetMessage() in a while loop is windows only and a pretty poor way of doing it. If that is the method used, then it really does need a revamp. Although the currentEvent on the Mac could be an analogue, there is no equivalent in Linux (x11) as that is purely asynchronous. The bottom line is, NI have to "hook" into the OS message system (either by polling or by registering) to be able to get messages at all. They just don't publish all the messages to us. Whilst it would be nice to have a few more "generic" frames in the event structure that are available across all OSs (after all, there are a lot of similarities), that doesn't mean to say they cannot provide the raw messages in a frame so we can write platform specific software (like we do with activeX and .NET). Especially if they can't be bothered to wrap some of the common ones up for us ........and don't get me started with VISA events! I'm also not buying the "lock-up" and "dangerous situations" argument. All these methods are standard event messaging that applications must use to interact with the OSs and have well defined wrappers in most other languages. There are lots of code snippets around and they are all pretty much identical since they just call OS api functions (or X11/Xorg in Linux). Hooking events is very straight forward (as you are about to demonstrate ). If the argument boils down to "it's hard" (which I refute since they are already doing it for "some" events - for all the OSs) then that isn't really an excuse for a $4,000 piece of software from a multinational corporation that is quite prepared to come up with a whole new paradigm.

Nope. I don't buy it. Lots of features work on one platform but not another (because it doesn't exist) but that is beside the point. You don't have to implement the "500 Windows Message events and its 2000 variants", just expose the message hook (which they must already be using for the Event Structure on all platforms) and let the labview user filter what messages he/she wants with Gcode.

Rolf is about to give you a much better way

Yeah. snippits are a bit of a pain (better to post the code). In other browsers (like firefox) you have to open the image in a new tab/window, save/drag it to the desktop, then drag it to the VI.

Nice. If NI got off their arse and spent time on the event structure, they could easily have included this feature as a native part of the Event structure.

NI Data Finder

Software is like a fart. Yours is ok, but everyone elses stinks. LVOOP just ensures no-one can tell who farted

If someone has un-bridled access to the machine. Then there is absolutely nothing you can do to protect discovery from a determined effort (it is just a matter of time). It doesn't matter what the programming environment is since I could quite easily drop a hacked windows DLL and then all bets are off. Zeroing memory is a weak (but not inconsequential) way to protect passwords since I only need to fire up Soft-ice and I can see where it is in memory before you clear it. The hard part is finding it in the first place amongst the thousands of lines of code. As you can probably guess. A dialogue box is an easy way to find where to start and then following the code to find the string message sent to the OS. So it doesn't matter what code you write, that is the crack where I can place the crowbar . The main thing to bear in mind, however, is that a password is a means-to-an-end. A password in itself is of no use. It is the info it guards that is of interest. You could have the most secure program in the world but it won't be much good if the user writes down the password and puts it on a post-it attached to the monitor. The only purpose of a password dialogue is to prevent someone looking over your shoulder and reading it; no more. If it is a worry, then use a key and lock the PC in a room with no network. The issue is more about prevention and detection of malicious programs actually getting on to the machine in the first place without your knowledge (reducing the attack vectors) and, if they do get on there, preventing the info they glean from exiting the machine in a meaningful form (like your private PGP keys) or, at the very least, making it difficult to extract meaningful info if info does get out (like your customer database). Isolation from the interweb ( ) .goes a long way to minimising this as does not having USB ports (or those ancient things called flippies or something). If a keylogger does get your passwords, then it's not a lot of use if the file that stores them can't be sent to the intended recipient. This is why generally more emphasis is placed on encrypting data since if you assume that the passwords are unavailable then there is a lot you can do to protect private data,

It's common in parallel testing on production lines (if I get what you I think you are asking). For example.Say you have 10 fixtures but you can only test 2 simultaneously (because that's all the hardware you have). When one test completes, it moves to the next non-tested fixture. In between changing from one fixture to another, all tests have to wait so that the switch MUX can re-route to the probes of the next fixture so any test in progress has to reach an arbitrary completion point (finish its current measurement) before the other test set can move on. If fixture "1" fails (i.e the overall test time is is also variable - failure results in a reduced completion time) then it must move to "3". It can only do so when the test set at fixture one has finished its current measurement (once test set "1" has moved on, test set "2" it will continue). Additioally. If "3" also fails, then it moves to "4". If fixture "2" then completes, it must ignore fixtures 3/4 since they have already been tested and move to "5" and so on.

Apart from the aforementioned aspects. Another major reason is that Industrial PCs have a guaranteed availability and parts longevity with a definitive obsolescence time scale (usually 5-10 years from introduction). They also tend to come with things like RS485, serial com ports and oodles of usb ports as well as the large PCI /PCIE count..

If it works. It's good. There are many ways of doing things and whilst there are "accepted" solutions to common problems; "Smart" is subjective. Your only objective was to "sequence" the drive shutdown since LabVIEW is inherently parallel, and there are a lot of ways you could have achieved that. For example. In addition to your solution, you could also have wired the error terminals on the express VIs to outside the loop (a very common way of sequencing VIs). or for that matter, the 0. You could also have OR'd the STOP boolean to the selector. Worry about "smart" when you know where all the things are in the palettes, you've got a few utilities in your toolbox, written a few programs and been on some courses. This program is the "first pass" (your prototype, if you like). I can guarantee you will be revisiting it making it "smarter", prettier or more flexible. The stop button in the IDE is for the developer only. In deployed applications, users should not have access to it since it circumvents shutdown procedures by stopping the code dead. Never give the user any opportunity to do something you are not expecting otherwise he/she will!

Just put another motor stop (set the motor value to zero) outside the while loop so that it gets executed after the while loop stops. I'll leave you to figure out how to sequence it to make sure it happens after the loop stops rather than while the loop is running (hint, don't use sequence frames, ever!)

Give this a go. not sure I got the "sense/direction" you are trying to achieve right (and had to reorganise a bit to make be able to read it). but the "latching" is there.

The output will be "TRUE" if the direction is detected. It looks like your case structure is set to "False" to turn off. Try swapping the cases around. It is usually better to post your VI or an example of what you are trying to achieve rather than an image. For simple VIs you sometimes get back the VI with the changes. There is a lot of replication in the openG VIs, presumably for completeness. Not using the openG stuff forces me to look in some of the more obscure palettes.