eaolson

QUOTE(EJW @ Feb 19 2007, 12:49 PM) I initially thought you could use a queue, but I forgot that fixed-size queues aren't lossy. You could use a queue, preallocate it, flush it, then start putting elements into it. You'd have to check if the queue was full, and if so dequeue an element before putting the next one in. I wouldn't use the Rotate 1D Array function since it reallocates the array. You could use an array in a shift register and an index to the next data point. Basically, create an actual double-buffered data structure.

QUOTE(Jeff Plotzke @ Feb 18 2007, 10:34 PM) I also found some significant slowdowns on an RT controller when using property nodes immediately after a reboot. In my case, I was using the Task PN to find the devices in a task. I'm not sure if these are related or not; in my case, waiting before calling the PN did not seem to help. http://forums.ni.com/ni/board/message?boar...ssage.id=210246

QUOTE(JStoddard @ Feb 16 2007, 01:46 PM) For a chart, you can use a property node and use the History Data property to get the contents of the chart as an array. It will discard everything not contained in the chart history, though. For a graph, you can just use a local variable of the graph itself. I would suggest logging the data to disk as you collect it, though. Unless you're collecting at really high rates, it shouldn't slow anything down. If a power glitch can lose 24 hours of data, it's worth the small amount of extra work.

QUOTE(Michael_Aivaliotis @ Feb 15 2007, 05:39 PM) You also can't use ; when searching for files in Windows. It seems to ignore the ignore the character completely. So I guess the question becomes: which is better, a function that works in every case, or one that prevents you from doing certain things, but gives you some extra functionality in exchange?

QUOTE(Michael_Aivaliotis @ Feb 15 2007, 04:13 PM) I'd just like to point out that the semicolon is a valid character in a filename, at least in Windows. So this would actually reduce the functionality of the list folder function. It seems to me it would ideally accept an array of patterns, rather than a single delimited string.

Interesting. I've only fiddled with scripting a little bit. It looks like the pre-cast StringConstant refnum and the post-cast String refnum are the same. So does the Type Cast primitive manipulate the actual data (i.e., the thing the refnum is pointing to) in any way, or does it just cause the block diagram editor to interpret the data type of the wire differently? It is possible to get yourself in trouble with this trick. For example, a String has the Default Value property, while a StringConstant doesn't. Trying to modify the Default Value of the StringConstant this way throws error 1058, "Specified property not found" at run time.

I noticed the whole "Icons have a limited pallette" thing a few months ago, and found it incredibly frustrating. I selected my color, went back to the icon editor, started using it, and my icon just didn't look right. So I went back to the color picker, thinking I'd grabbed the wrong color, started using it again, and it still didn't look right. I finally managed to find something that looked acceptable, and gave up trying to figure out what was going on. The frustrating part was that the color picker dangles all those colors in front of you, but whisks them away when you get back to the editor, without mentioning that it had changed your selection. It's not mentioned in the documentation, either. Why the 256ish color limit in the icons, anyway? Does it just harken back to archaic times when we had 8-bit monitors and, darn it, we were glad to have that?

That sounds like NI is trying to assert ownership of the copyright of any compiled VI. Surely not?

It looks like they're pretty much using the web-safe, 216 color pallete. There's a fantastic representation of it here. Which makes me think: would it be possible to exchange the color picker in the icon editor with something more useful, much like how Mike Balla's Icon Editor can be dropped into the right location to use instead of the default one? There's not a lot of reason to have a color picker with millions of colors if it only lets you use a few of them.

I'm no lawyer, but I don't really see what the problem is. Creative Commons Attribution 2.5 allows you to (a) copy and distribute the work and (b) make derivative works. In exchange you (a) attribute the work and (b) distribute the CC license. The BSD license basically allows you to do the same with the same restrictions. Functonally, they don't seem to be significantly different. One thing I've never understood is where a derivative work stops and starts. If I take say, one of the OpenG string VIs, and modify the functionality a bit and rearrange the terminals, clearly it's a derivative work and it falls under the OpenG BSD license. If I then call that modified OpenG VI in an original application to, say, fly the Space Shuttle, does that mean my application as a whole is a derivative work or not? Under the old LGPL license, it seems it would be if the application and all its sub-VIs were compiled to an EXE. (I assume that's why the transition to BSD is under way.) But LabVIEW seems to sort of compile on the fly, so would it be a derivative work when its running under the development environment? When it's loaded into memory but not running? When it's just sitting on the disk?

I doubt it would be too difficult, but they're slightly different. If you think about moving something with a mouse, the intuitive way of thinking about it (in my opinion, your brain may vary) is that the object moves in the same direction as the mouse movement and when the mouse stops moving, the object stops moving. Speed of the object should be related to the speed of the mouse movement. For a joystick, the tilt direction controls the direction of the object's moton, and as you tilt the joystick it moves faster and faster. If you push the joystick all the way forward, the object moves and keeps moving until the joystick goes back to its center position. Basically, a mouse controls position; a joystick controls velocity. The nice thing about the serial mouse is that the protocol is simple, well-documented, and implemented by a number of manufacturers. There's a three button one, as well. I don't think the same is true for joysticks.

Plugging the mouse in after the computer boots is exactly how I do it. I've always had the vague impression that hot-swapping peripherals was not such a great idea (USB being an exception), but have not had any problems doing it to date. The reason I wrote these VIs is because I wanted some user input to a program running on a PXI system running LabVIEW Real-Time. Since there is neither mouse or USB support, this was the best solution I could come up with. There, of course, leaving the mouse/trackball attached to the COM port all the time is just fine. Serial mice are still out there, if barebones. I picked up a $4 one for testing. Most industrial trackballs seem to have a serial version available, as well. This is my first contribution to the CR, and pretty much the first thing I've released for "public consumpton." Comments and suggestions would be greatly welcomed.

File Name: Serial Mouse Driver File Submitter: eaolson File Submitted: 22 Jan 2007 File Updated: 23 Jan 2007 File Category: General Serial Mouse Driver for LabVIEW v1.0.0 Copyright

No, I only noticed it because I clicked on the wrong bookmark by accident. I guess I just wanted confirmation that DataAct had not gone out of business and that, if I ever needed a fresh installer for dqGOOP, I wasn't up a creek.

I've been unable to get to the DataAct website for a couple of days now. The domain name hasn't expired, but the DNS doesn't resolve. I'm hoping this is temporary. Does anyone know?

Ah, but what if you put the pressure cooker in the microwave?

I did not realize this method of starting a background application did not work if it was compiled into an executable. Using a launcher (separate VI that opens a reference, runs the VI with Wait Until Done = F and Auto Dispose Ref = T, then closes itself) also doesn't seem to work with a compiled application. This is a bit tangential to the original topic, but is there any way to have an executable application running in the background and not visible without using the FP.State property? (I'm still trapped in the land of 7.1.1, so I don't have access to it.)

I asked because RagingGoblin posted a link to an NI example using FP.Open, but the image he attached used FP.State. I wasn't sure if there was a specific reason for the discrepancy, or if he was just taking advantage of a version 8 feature that wasn't available when that was written. (I swear I wrote this yesterday, but it's not here today.)

Is there much of a difference between hiding the application by setting the FP.State property to Hidden and closing the front panel by setting the FP.Open property to False?

Ah, looks like this was fixed in 8.20.

I posted this over at the NI forums, but thought I would bring it up here as well. The configuration file VIs Read Key (Path) and Write Key (Path) don't seem to work as expected (at least not as I was expecting them to) on an RT target. When working on my WinXP PC with these two VIs, paths are translated to what looks like is supposed to be a device-independent format before being written to disk. The path C:\dir\file.txt becomes /C/dir/file.txt when writing and vice versa when reading. On my RT target, however, that same path is written to disk as C:\dir\file.txt, unchanged from the native format. The translaton of a native path to and from the device-independent format appears to be the responsibility of Specific Path to Common Path and Common Path to Specific Path. These both use the App.TargetOS property to determine the operating system. In the case structure for these two VIs, however, there is no case for PharLap or RTX. (My RT hardware is runnng PharLap; I don't know enough about RTX to comment.) This means that the results of String to Path or Path to String are used without translating between the device-independent format to the native path format. This isn't a problem if you create a configuration file on one machine and use it on that same machine. I noticed this only when tranferring a config file from my PC to the RT target, where the target would not open the file paths it loaded from the configuration file. This occurs on 7.1.1 and 8.0. I don't have 8.20 to see if happens there, too. It also affects the OpenG variant configuration functions, becuase they eventuall call the LabView configuration VIs.

Is anyone else waiting with baited breath for the next coding challenge for that very reason?

It seems like both variants and flattened strings allow one to pass data in and out of a VI without needing to know what the underlying datatype is. Is there a reason to prefer one over the other in this instance (e.g. speed, memory size)? There are other applications, I'm sure: Variants have attributes (but I've never really seen the point of those); and TCP communication requires the use of strings. Variants carry with them information about the datatype, but you still need something of the appropriate datatype to use Variant to Data.

By this, do you mean that another VI can not obtain a refnum for an unnamed queue created elsewhere (i.e., with Obtain Queue)? I have no problem creating an unnamed queue in a top level VI and passing that queue's refnum to a subVI for use there.