hooovahh

Well, one could argue that any CRC sucks, as there aren't completely mutually-exclusive signatures for all possible permutations of a string input.

This is an important thing to remember. Any CRC/checksum method will have multiple messages generate the same result. There are an infinite number of strings that will return the same MD5Sum for example. The likelihood of having two random strings generate the same MD5Sum is 1 in 340,000,000,000,000,000,000,000,000,000,000,000,000 (rounded down). Similar things can be said for GUIDs.

There have been several attempts to break MD5 in a systematic way and I believe someone was able to but I can't seem to find the example at the moment. The example was a EXE that when ran would say "Hello Wold". Then there was a second EXE with the same MD5 and when it was ran it would say something else.

Like Chris said...

You may want to address him as crelf only because there is more than one person in this thread, with a real life name of Chris.

Yeah I totally agree that this should be a native LabVIEW function in the event structure. There are a few idea exchanges suggesting this, some with more votes than others. Here's the one I found with the most number (currently 229).

http://forums.ni.com...nt/idi-p/921547

EDIT: Currently this is the 16th most common kudo'ed idea.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas/status-key/new/tab/most-kudoed

This all sounds great. For some reason I thought this was done in some LabVIEW challenge a few years ago was it not? I can't seem to find it at the moment.

Well you are at a LabVIEW based community forum so I'm going to guess most people would tell you to stick with LabVIEW because of all the diverse fields that LabVIEW is used on, and for the large range of hardware and applications.

That being said careers can change, and it may be a good idea to try something new. Keeping your options open is always a good idea and by trying out PLC and learning that field puts you in a better position down the road for other employment opportunities where you can say you are both familiar with PLCs and LabVIEW, but are not an expert in LabVIEW.

It's your decision to make, but don't worry about if you made the wrong decision down the line. Things can always change and you can choose the other path in a few years if things don't work out. Or take on a completely different career that has nothing to do with programming.

You absolutely can detect the event of a scroll wheel (at least in Windows). You use the Windows Message Queue to detect the scroll and fire a user event.

http://forums.ni.com/t5/LabVIEW/Mouse-wheel-scroll-event-ON-CHANGE/td-p/860112/page/2

Checkout the Scroll_Event_V2.zip file it has a nice example inside.

I'm not sure what parts of the registry you need to modify, but I believe that since Windows 7 the user level of the registry doesn't require admin access. So if your application is writing and reading values for it's own self then you can try to use this section of the registry and not need high level access.

Also I'm not sure your environment but under some circumstances the easiest solution is to just lower the UAC level down, so that it won't prompt when an application tries to modify that level of the registry.

It should also be noted that you can ready any part of the registry without increased user access if you perform an Read-Only on the open VI.

I may have missed it but where did it say it was controled with LabVIEW? Not that Intel would consider that a selling point for their product.

You can tell the one on the right has had light deprivation, which is why the monitor brightness is on maximum. I can't tell if they are wearing a white shirt or the brightness is washing out the color.

You're not the first person to suggest we look alike...

The resemblence is uncanny. I'd go so far to say that an automated image search alorithm thought you were the same person.

Wow I'm a little ashamed to say that I've always done a print screen, pasted my whole screen into Mspaint, then selected just the primative I wanted, copied and then pasted into the icon editor.

Also I believe that Flickr allows you to search for images in the public domain, or royalty free. The site is massivly slow for me at the moment so I can't check but I think that's where I saw that feature.

I have never heard of being able to use a FPGA board with LabVIEW, that wasn't a NI FPGA hardware solution. I'm not saying you can't use a different board I've just never heard of anyone doing that.

If you must use NI hardware (which I suspect is the case) the cheapest PCI model is going to run you $1500 just for the card, which is a DIO only card at 40MHz and 1M gates.

http://sine.ni.com/nips/cds/view/p/lang/en/nid/202011

That's not including the cables or terminal blocks.

One other possible option is develop in LabVIEW, then compile to VHDL, then burning that to your generic FPGA card. I've never done this and am unsure if it can be done. I assume at some point the compiled VHDL code is available but you will probably have a difficult time properly addressing hardware IO on a different FPGA.

One thing to just be aware of with it is fragmentation. It's a common problem that we see, esp. on embedded platforms where file size is more sensitive. There is a white paper describing the exact implementation but the short version is that each time you use TDMS Write a "chunk" of data is written to file (Im not sure if this is the proper term). If that chunk matches the previous (same channels, datatype, I think size) then it is written just as binary data and maintains the efficiencies. If it does not match then it writes a new piece of XML header data with the data, which is very inefficient. The result is if you mix the reads to a single file your XML header becomes huge, as does your file and your access becomes slow.

The solution is to try and keep to a single write function to stream to disk. If it is unavoidable then there is a TDMS defrag function which will then reduce the size again but this can take some time and CPU.

This is true but one work around is to set the buffer size of the channel before writing the first time. This will allow you to use the write function several times without it needing to actually write to disk, which means it will not need to write the XML header. The down side is the data is not actually written to disk, and if power is removed from the PC then your buffer is lost. For this reason I try to make my buffer size appropriate, so I'm not writing XML header data all the time, but I also don't have a buffer so large that I don't write all the data at once (unless that is desired).

http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/setting_tdms_buffersize/

I was disappointed when I went to their talks page and the "Wat" talk was the only one there.

This was actually discussed in this thread and in this thread.

Yeah it was and it was even posted by the same user. It would not surprise me if our labviewsolutions was the owner of the domain.

A few things to be aware of is the application may look different because of the themeing controls and fonts that are used are different.

Also be aware that with UAC in Winodows 7 you may not have the ability to write registry. Even as an administrator you need to turn UAC down to be able to write in most of the registry (user access may work I'm not sure).

Not specifically XP to 7 but also be aware that with 64 bit Windows OSs have a "Program Files (x86)" folder and that hard coded paths to C:\Program Files are bad.

That also reminds me that hard coded paths to "C:\Documents and Settings" are also bad and should be using system variables to user files or temp files.

Assuming you avoid, or are aware of these issues it should work just fine.

Could you tell me of a post that describes your solution in details with examples?

I didn't think a snippet would work properly so here is a quick example of what I was thinking. It just has four buttons, exit and three for triggering events. Event 1 fires one event, Event 2 fires 2 and Event 3 fires 3 events in the predefined order. What the events actually does isn't important but in this example it shows a dialog saying what the previous event was (if there was one) and what the current event is without using any local or global variables.

Queued Message Example.vi

I'm sure others will chime in on their opinions. But some of the benefits I know of are...

Direct DMA streaming from channels to disk including channel scaling and settings (my understanding is this happens without CPU intervention).

Small file size with combination of binary and XML data.

Reading TDMS data is quite easy using the TDMS palette, and you don't need to read the whole file to get the data you need. Grab the group, and channel and display it on a graph. Data is found based on names not column or row indexes.

You can concatenate TDMS files using a binary copy function (copy /b in command line) and channel data will be appended.

Using properties of the File/Group/Channel helps with organization and header data.

Can be opened in Excel with a free add-on. (and looks decent where things like column width and font style on import, that you don't get on open in ASCII)

Can store just about any data type. http://lavag.org/top...in-a-tdms-file/

Works nativly in DIAdem for automated report generation (not much experience with this when needed I have written my own in LabVIEW)

Can be opened in Matlab (not much experience with this either but I heard there are drivers)

Comes with a half way decent file viewer, which can be modified to your needs.

I started using TDMS files for storing development and debug data. Then I started putting the actual data for what I was doing in there. Now when a test completes I can take that TDMS file, and generate a more formal looking report from it. This way there is a nice looking report with the data we care about at the end, but we still have the TDMS file which will contain all raw data. But when it comes down to it use what works for you. TDMS maybe overkill, or you might not feel comfortable using it, and that's fine. For me it works well, but it might not be right for every system.

You are on the right track but i would suggest adding complexity to your code, in the hopes that it will make it more reusable, and easier to understand. I usually use a while loop, with a case statement in it, and then a event structure in the default case. (I believe the JKI template uses a modification of this).

Another way to make this design is to open the LabVIEW template, Queue Message Handler and add an event structure to the default case.

What this allows you to do is have most of your code in the cases of the case statement and not the event structure. So say you have a button that does some function, say call another sub VI for a dialog. You can have the button's change value event call three cases "Hide UI", "Show Dialog", and "Show UI". Now if you have any other functions that need to use the "Hide UI" or "Show UI" then you just need to call the cases. So for you there could be four cases "Event 1 Steps"..."Event 4 Steps". Of course I would recommend using better naming for the events. Then you can call any number of steps in any order, under any event case.

I believe this to be the more right way, but one way is to do as you said, where you have a value signaling property on a control that calls an event. I feel like this is harder to follow, and harder to debug.

Keep in mind that scripting does not work in a run-time environment. Meaning it won't work on a system that has a built EXE running, it will only work in a development environment.

I don't have vision installed on this machine, but if this is the example I think it is, your problem is with the fact that the IMAQ Get LCD ROI gets the ROI of the LCD by looking for 88 on the display. You can look at the help and it will create a ROI for the LCD if the 88 (or in this case 8888) is shown on the start. That's why the example will load the 88 first, then cycle through the other images (after the ROI has been setup).

Create a ROI that goes into the IMAQ Read LCD sub VI that is setup to have 4 ROI (one for each segment) and it should work.

I may be wrong but doesn't DSC also come with some kind of image library (not sure exactly what it's called) and all the neat-o xcontrols? Okay so I don't use them much but there were some pipes that have interesting bending properties.

I'd also be curious to know if someone has examples on how to essentially take over the serial port manually. I found this knowledge base that looks like it may help you but I've never done it personally.

http://digital.ni.com/public.nsf/allkb/1ECEFAA7AD52994986256966005356EA

My Question: How can I do any one of the following:

A. Produce a cluster of strings from an array of strings?

There is an Array to Cluster in the Cluster palette. You must specify the size of the cluster to make (the default is 9), right click the primitive and select Cluster Size. This is not changeable at runtime as far as I know.