David Boyd

Of course, to be really faithful to the retro look, you would need to have paddle switches with labels like 'Examine' and 'Deposit/Next'. Something similar to this... ...perhaps? Dave

Without having actually used the feature yet (he said authoritatively ), this sounds like an excellent place to try developing an XControl. Something along the lines of a cluster of booleans which capture keystrokes, test for 1's and 0's, and increment an active location while toggling little retro-PDP-8 paddle switches. Any chance you have LV8 but haven't broken the shrinkwrap/updated your LAVA profile? Not an especially useful reply - but perhaps one to get others thinking... Dave

I posted this to Info-LabVIEW, but for the sake of reaching the widest audience: A very big THANK YOU (SPASIBO BALSHOYE!) to Stan for putting the effort into making this work under LV8. (And my apologies for not doing it myself - I had a beta copy of 8 ages ago, and never tried the TWW under it, what was I thinking??) And while we're talking about classIDs changing, here's one for the wishlist: it would be very handy if it were possible to wire a class specifier constant (the little green/yellow tag) to a property node and have it give you the classID value. Currently, the property node returns an error 1055, Object reference is invalid (of course) and default data (zero) for the classID. This would have saved me from having to use numeric constants for the class testing. Of course, I could have tried to test-cast the generic refnum to each class of interest, and handle the error case - but I chose not to do that. (Who knew that classID values were going to change with a new release? I assumed, incorrectly, that they would just be adding new values for new classes). Thanks again to Stan and Paul Sullivan! :worship: Dave

I finally remembered to check whether the release copy of LV8 fixed the bug described here. Looks like it hasn't been addressed. Dave

Jim, This is off-topic, but something that got me curious. Can you share with us how you get your BD annotations? I can't find any built-in LV decorations that can be modified to reproduce the thick-lined ovals and rounded boxes, arrows, etc that I see. Some of your stuff looks enough like the Pro differencing toolkit that I'm wondering if you've got some tricks up your sleeve. Or maybe you're just retouching your screenshots with MS-Paint... Left wondering, Dave

I think your problem is your BT stack. Unless something's changed, the following quote from the NI KnowledgeBase indicates that LV won't work with a BlueSoleil-managed BT radio:

Mikrobi, I'm glad you found your solution. And my apologies, I should make a rule for myself to never post an answer without having LV running on my screen. The "date time rec" cluster which is input/output of the "Seconds to Date/Time" and "Date/Time to Seconds" primitives, DOES NOT include a milliseconds member. This misstatement on my part was my faulty memory talking - long ago I wrote routines which separately manipulated the fractional part of a timestamp. Happy to be helpful, Dave

Mikrobi, Perhaps if you elaborate a bit on what you mean...? If you're talking about timestamp controls, indicators, and BD constants, you can context-click and edit their format to display digits to the right of the decimal point. If you're asking about data manipulation, you can add and subtract fractional seconds to timestamp wires using the add and subtract primitives. And if you want to decompose a timestamp into years, months, days, hours, or re-compose one, the 'to' and 'from' Date/Time primitives (sorry I can't remember exact names while I'm away from LV) will give you a 'milliseconds' output or accept a milliseconds input. Does this answer what you were asking? Best regards, Dave

Mule, There really are no risks or downsides in terms of performance, maintainability, etc. that I know - this one falls in the realm of style. There's been a suggestion from time to time of having a way to show a typedef'd constant on the BD in an iconic style, since large constant clusters tend to look messy on the BD, and when typedef changes propagate, any modifications the programmer might have made to the constant's appearance are lost and the constant reverts to a standard layout. Making the data source into a control and then hiding it cleans up the BD, but just 'feels' wrong stylistically, if only because controls are supposed to pass variable values into the dataflow. Dave

Another possible option (which I've only recently adopted) when I want a named, type-defined constant on the BD (frequently just to use as wire-typing source into a named bundler):Don't use a constant at all. Drop a typedef'd control on the FP, set up its default value(s) (if they're needed). DON'T attach it to the conpane. Optionally, deselect 'Autoupdate from typedef' if you want to force the BD to be revisited/reinspected if the typedef changes. Context-click its terminal on the BD, choose 'hide control' and also 'view as icon'. Pros of this approach: Tidy on the BD. 'View as icon' makes it clear the source is type-defined. Cons: There is still a control, lurking invisibly, on the FP, that's not used to pass data into the VI. (Guess I'm paranoid - this still troubles me a bit.) Or did I miss the point? Dave

Hmmm... The calculation obviously produces a mean.... it's in a square frame..... (root) mean squared..... mean squared (error)..... Guess I'm just too dense this morning, sorry Joe. Dave

I would hesitate to call them 'worst', since they are functional, but two that I've encountered which illustrate your point are the vendor-supplied drivers for TSI flowmeters, and the Tescom ER3000 series pressure controllers. In both cases, the devices have clearly documented serial interfaces; in both cases, the drivers are thin VI wrappers around DLLs which do all their own serial port management. Along with this method comes the inevitable problem of nonportability, nasty surprises when the com port isn't plain vanilla COM1 thru COM4, etc. My take-home message is this: there are a great many journeyman C programmers, or design engineers who know a little C, who get told they have to offer LV support because big customer X requests it. So they wrap LV around their homebrew DLL and declare the job done. In these two cases (and others), I got the serial interface spec, put it in a little binder, and started coding a pure-G replacement. I created typedefs for all the little param lists, etc. I even made up consistent icons with the vendor's logo/colorscheme/typeface, which of course they didn't do. Best regards, Dave

Sorry, Michael, you missed that one entirely... Note to jeffwass: Sum of us got the joke. Dave

Rolf,Perhaps I missed a discussion somewhere - has there been an announcement from NI about formally supporting scripting and a licensing scheme for its use? I'm not doubting you, of all the people on LAVA or Info-LV (outside of NI) you would probably know. Just wondering. With best regards, Dave Edit: Just saw your other post in the scripting forum. Can you tell me more particulars about licensing under LV8? I've only partially switched to the release version of 8 (still waiting for the updated VLM and a new license file) so I haven't explored the issue yet.

I would've preferred that someone else on LAVA with more experience with RT would have replied by now, but since no one else took a stab at it... I'm relatively inexperienced with RT, having only a short handful of FieldPoint RT systems in use since last year, so all my answers are suspect. My reasons for using RT devices were pretty similar to yours - less about determinism and more about the promise of runs-like-a-tank long-term operation. In this regard, they've delivered as promised. As has been pointed out, you do trade off some capabilities. In one of my applications, periodic logging of measurements was an essential. Since the NI Report Generation and Database Connectivity toolkits are ActiveX-based, they're out. My needs were simple enough that I could just maintain a delimited-text file in the FP device's flash memory. I setup the built-in web server to show the application's top-level VI (current status), and in the HTML I added a link on the page to open the text file. Then I setup the webserver's MIME types so the remote user's browser would load the file into Excel on their machine (which handles delimited-text files even if you give them .xls extensions, I found). Of course, they still need the LV runtime support installed so their browser can see the VI panel embedded in the page. The RealTime module is installed on the development PC as an extension to the LabVIEW development environment. This adds the capability in LabVIEW to change the execution target (from the default host environment) to the RT device over Ethernet. The VI files live in the development PC's filesystem, but when you run the VI, the generated object code and FP resources are pushed to the RT target's memory. The development PC then manages the FP interaction. At this point you can cut the RT target loose (by closing the LV editor, or targeting another RT device, or retargeting the host environment). The RT target continues to run. Note, however, that the RT target will not resume running this code if it's rebooted. To do THAT, you need to have built a startup application and FTP'ed it down to the RT target. The LabVIEW application builder (I assume you have this already) gets extended functionality when you add the RealTime module, so that it knows how to build executables which run on the target hardware, push them to the target via FTP, and set the RT target's INI to launch the exe. Maybe it's just me, but it took me awhile to get the concepts sorted out after years of just running LabVIEW code on a PC. I believe all the FTP particulars on the target are manageable through MAX. I admit I haven't made a big study of security. There's security related to what IPs can access FieldPoint hardware (if your RT device happens to be FieldPoint), and a feature to lock the RT target against settings mods and reboots. Having just now looked at the NI knowledgebase, I see that the 'lock target' feature applies the same password to the FTP server, which ignores the username. Anybody with a copy of LV can develop VIs which will eventually run on the RT target hardware, but the development PC must have the RT module installed to interact with RT target hardware.Even after all the develpment is done and the RT solution is fielded, you still need a PC somewhere if humans are going to interact with the process. So as far as FDA compliance is concerned, you've only offloaded part of the controlled software. But this may still be more palatable than administering Windows-based PCs which directly connect to the controlled process. Hope this long reply is of some use to you in your decision-making. Best regards, Dave

AFAIK, we've never met, so I can't say much about your mental state (reminds me of a joke: What do two psychiatrists do when they meet on the street? They shake hands and say, "You're fine, how am I?") But seriously... There are various TrueType fonts floating around which can be installed on any Windows PC, some for free. I've attached a code-39 font I've used in the past for this, I hope it's freely distributable. I would suggest that you put a string control on a VI front panel, set the control's font to use the BC font at an appropriate pointsize, color the control's other parts white or transparent, color the panel BG white, and set the VI to print on completion. You call the VI, passing the string you want (you may have to bracket the text with leading and trailing asterisk chars, for the code-39 font to render correctly), and out comes paper with a barcode. So, if you're crazy, I must be too. Best regards, Dave Edit: Having trouble getting the attachment to stick. Will try again and get Michael's help if necessary... Perhaps I can get the font file to attach to this post. Dave (keeping fingers firmly crossed while typing). No go - but I found a weblink where it can be downloaded: 3 of 9 barcode

Are we sure this is incorrect behavior? Is the definition of equality whether the refnums refer to the same VI object, or the same instance of the VI including its dataspace? (Or am I just adding noise to the discussion?) Dave

Awww, m3nth, even as I wrote it, I knew somebody would 'gig' me for posting that. Actually, what I did in another util which used scripting and recursion, was to cast the refnums to longs and back on the trip through the conpane. That was my first idea for preventing folks from cloning the scripting classes. So many clever people on these forums, I just can't keep up with all this stuff. Later, Dave

Ouch! If you were referring to my post here, please re-read the subsequent discussion at the time and note that I was only joking. My real reason for locking the BD: because scripting was so new to us, and not a feature that NI intended to support to end users, I was reluctant to expose the undocumented nodes I had used. That utility has been d/l'ed, it seems, by just about everybody. I know that I've given the unlocked copy of it to several people by private email; I guess I somehow thought it had ended up on LAVA. All the scripting methods and properties it uses have long since been discussed and documented elsewhere anyway. This is probably the wrong thread, but as my public act of contrition, I'll attach it here. Note to Michael: if you want to move this post, or replace the locked-BD copy of the util with this one to save space, feel free. Best regards, Dave P.S. And the BD of the TWW is messy. Since we're on a discussion of style anyway, let me just say in my defense: If you're writing a scripting helper that watches for VI activation, object selection, etc., you currently have to loop and poll I deliberately did not break the code up into subVIs because I would have had to pass scripting object refnums, thereby exposing them Download File:post-195-1128601774.vi

Norm, As a follow-up - I played around with this a bit and though my brain is too tired to figure out the LV coordinate system at this late hour, I did learn two things: Create Described Wire does not replace the existing wire, I had to invoke Delete on the wire refnum (obtain its terminals first!) it's very easy to create lots of broken wire segments trailing off from your 'good wire' if you don't have a Cartesian clue I can't count Best, Dave

Norm, So, you've got an array of wire refnums, is that correct? And you want to script a way to move them around without changing the actual wiring? I hope I've got the task correct. If so... A wire refnum has properties for the Terminals[] which it connects. There's always one source and one or more sinks. ( I think I saw somewhere that the source is always the zeroeth element, but I'm not sure.) A wire also has a read-only property, Joints[], which describes an array of clusters of segments and branches. The problem here is that the wire's Joints[] property is read-only. BUT, if you get references to the Terminals[], and figure out source and sink(s), there's a method on a Terminal refnum for 'Create Described Wire'. I think you can invoke that with your computed array of junctions and segments (how you do all this sounds like quite a chore, good luck ), and LV should replace the existing wire with the described wire (since redundant wire paths were rendered impossible to produce starting around, I think, LV 6). Is this what you want to do, or did I miss the point? Best, Dave

You should read LabVIEW app Note 154, LabVIEW Data Storage, if you haven't already done so. LabVIEW floating-point values use the IEEE-754 standard for storage and manipulation. A LV double is stored in eight bytes, a single uses four bytes. You can directly convert singles and doubles by wiring them to the 'Type Cast' primitive, found under Advanced->Data Manipulation palette. You'll get a four- or eight-character string as output. (LV strings are the preferred representation for arbitrary byte stream data.) I'm unclear on what you need as your ultimate output. If you want to get the single or double into a file in the smallest possible amount of storage, you're basically 'done' with the above steps - the string is 4 or 8 bytes long. Or, if you want to display or print a hex representation of this, you can do lots of things. You can wire the string to an indicator, and set the indicator to display in hex mode. You can convert the string to a U8 array ('String to Byte Array' primitive, String->StringArray/Path Conversion palette), then loop through the array and convert the values using the 'Format Into String' primitive, using a %x format - then you'll have a directly-human-readable output string (twice as long!). Hope this helps. My experience is that many people get very confused by the differences in representation vs. presentation available in LabVIEW when they first encounter a task requiring bitz, bytez, hex, etc. This is not a fault of LabVIEW, which has a rich feature set in this regard. It is often a problem with imprecise communication (between humans) over what they mean. By the way, I count myself among the people who've gotten confused over this. Hope this helps, Dave

Google on Q165721, a Microsoft KB article (roughly) entitled 'HOWTO: Eject Removeable Media in WinNT/2K/XP'. I didn't read all the way through, looks like they're doing DeviceIOCtrl calls. You may be able to use a couple of CLNs to access the Win32 system to do what you need. Hope this gets you started, Dave

The editor doesn't seem to check units consistency on a few of the array primitives. For example, an array of doubles with units of 'Hz' can be wired to an 'Insert Into Array', then a scalar double with units of 'psi' can be wired to the element terminal of the same primitive. No complaint from the editor; when the VI is run, it appears that the base unit values are used to perform the insert. (Incompatible units also includes the case where one input carries no units.) The primitive 'Replace Array Subset' seems to behave similarly. Shouldn't the editor flag the VI as broken? Dave

I'll vote for that. I only recently learned (from Stephen Mercer at NI) that setting a control's BD terminal to display as an icon (which I'd always thought was a waste of BD space) will render the typedef icon for controls tied to a typedef. It'd be great if there were a way to extend this to the typedef'd constant as well. Dave