Jordan Kuehn

Haha just saw that last night! I agree!

I think your best bet is to call NI. AFAIK that information is not public.

I notice the first profile file has the velocity sinusoid starting at its peak while the position is at 0. If I'm graphing it in excel correctly. Perhaps swap these?

Would you mind posting the PVT profile that generated this erratic behavior?

You can navigate to instr.lib in your LabVIEW exe folder, find the drivers and edit the lvlib so that the VI in question is publically scoped. Will this break anything? I don't think so, but I didn't take the time to find out.

It appears the Wait for Scan Complete VI is simply polling the hardware. Can you see how many times the loop iterates in a typical scan? If it is indeed polling at any sort of decent rate you can just pull out that logic and place it in your main diagram and add your stop button to the loop condition. This should let you keep the timing in the hardware. I do agree to be confused as to your insistance on using the device to time something as long as 15 minutes as that is what is creating the lack of responsiveness in LabVIEW.

Thank you for showing the settings; they didn't transfer well with the initial snippet. It appears the simplest approach would be to essentially take the measurement "on-demand" and use the VI to drive the timing as we have described, rather than having the instrument take 900s. How precise and consistent of timing do you need between measurements? At a 15 minute interval I would assume a few ms either way isn't a big issue.

Sorry for the confusing wording with all the "timeouts". If you need the scan to start immediately, you could run the scan once before entering into the while loop with the event structure. The short timeout input is in reference to the timeout input you have in your scan subVI. Currently it appears that you are feeding it a very large timeout. Can you share the values that you are using to configure the scan? If you have configured the scan to take that long it may require a different approach. This approach works just as well, and you could OR the output of that with a First Call? primative to get it to run immediately.

In your top loop you can place an event structure with a timeout value of the 15 minutes and place the scan code in the timeout event case with a reasonable (short) timeout input. Then in your other event cases you can process things like your stop button.

Are you talking about USB3 Vision compliant cameras? Then perhaps the timeline is correct. If you are talking about usb cameras in general, my previous DirectShow compliant comment stands and goes beyond 2009. PS. We all want cameras that work with IMAQdx. Unfortunately, often vision work utilizes emerging camera technology and can't use IMAQdx. C++/C# drivers often get written first.

Yeah, without more info from the OP there's not much more to say.

How does the camera interface with the computer? A quick google shows only analog outputs. ThomasGutzler is correct in that you probably need to make your own drivers and do the conversion to IMAQ images using the conversion VIs. If the manufacturer has a DirectShow compatible version it will make things very simple for you.

From the comments I see that there is some sort of vague licensing requirement for commercial use.

Well now I'm unhappy we paid for this awhile back. http://sine.ni.com/nips/cds/view/p/lang/en/nid/211148

Check out these threads and see if they help you. https://lavag.org/topic/18872-text-not-showing-up-under-semi-transparent-object/ https://lavag.org/topic/18931-3d-text-disappears-text-properties/

This. It can be very frustrating when Windows decides to rename all of your ports. Sure you can add additional code, but it's easily fixed with a better solution as mentioned by adding a physical interface card.

Using the same ROIs, focus on 1 and 2 right now, you can look at your edge detection results, threshold those to find a binary representation of your edges. Then I might suggest using those results to identify a region inside your desired object and a region outside to use their original values as inputs to your thresholding on the original image. Alternatively you could attempt to use the results of the edge detection to create a blob that roughly matches your desired object and use that as an image mask on the original image before doing further processing. Nothing is set in stone with Image processing; there are many ways to achieve a result. Some are better/more robust than others. As mentioned, you are always best off to ensure the best, most repeatable images (positioning, lighting, working distance, etc.) are acquired to begin with. I often tell customers that it takes 10x as much work to correct something in processing than in hardware. Regardless of the actual multiplier, it gets the point across.

This seems like an appropriate topic for a VI Shots episode.

The simplest way would be to utilize the report generation toolkit and populate a template. In your template you can have coloring rules based on the values you anticipate putting in those cells. Basically set it all up in Excel first and just fill in the data with LabVIEW.

In addition to all of this, it is important to be open with your customer. Nothing would sour the relationship faster if you try to sell yourself as more than you are and you fail to deliver. Obviously don't undersell your abilities, but be up front and let them know that there are portions of it that you are not entirely familiar with. If I were the customer I'd probably be looking for a fixed price knowing all of this and would expect to pay less than I would to an established consultant. On your end, make sure to get everything spelled out in your proposal to make things clear for all parties and to protect yourself from feature creep. You'll be more than willing to add features for more $$.

You'll likely want to read it as a string and take care of converting between strings and numbers and back. Look for number/string conversion in the string palette.

Not the way I expected this sentence to end.

You may have some luck with getting your local sales guy to put you in touch with R&D to give you an "unofficial" max limit on the hardware that will at least give you an idea of how terrible that current will be for that short duration and possibly an idea of what components could fail. Worst case they'll tell you that you absolutely cannot exceed the specs listed. I agree with Hooovahh that these specs seem a bit different than the typical spec sheet.

I've nearly abandoned TDMS for these reasons except for in special cases.

This is amazing!