infinitenothing

Does it take xy data or just waveforms and intensity plots?

I appreciate your requirement gathering. Ideally the algorithm would use as many points as possible so if there was only maybe 10% overlap (see image below), hopefully it would be able to work, and if there was 95% overlap, ideally, it would use 95% of the points for the match. The offset won't be bigger than ±0.02 I think I understand the solution you suggested. You mean interpolation right? I can probably make that work but I was hoping that someone knew of a more standard way of solving my problem. No reason to reinvent the wheel right?

Thanks for the input. I'm using 2016 but I used the code capture tool to try and backsave it in 2009 incase someone wanted the dataset. Here's some potential issues I'm concerned with. (last minute requirements ): The size of 10 points for the pattern seems arbitrary. 0.5 tolerance also seems arbitrary The X data isn't really used. For example, your method assumes that the two data sets will be evenly spaced and equally spaced. Fortunately they are pretty close in my example but I'd rather the algorithm could elegantly handle the data if the second data set had 25% more space between the points. You seem to only be moving the index in increments of 1. That means that I could have an error of up to 0.5 dx.

I have xy data for two waveforms (on the left). I'd like to figure out what's the offset between them ignoring any points that aren't in the waveform. Right now I'm just grabbing the peak but if the signal get noisy that might not be a great idea. Is there a way to take into account the whole functions?

If you're looking for NI's web service examples to walk you through some of your links look here: C:\Program Files (x86)\National Instruments\LabVIEW 20xx\examples\Connectivity\Web Services You won't need the RTE on the client computers but you'll also have very limited interaction. Think text and pictures and not panels. If you need a remote panel look into the above post. You should also look into your client requirements. Some other options open up if you are willing to run silverlight or flash. Those options are becoming obsolete over the next decade or so.

Sounds pretty easy. Get a smart cam and a ring light. I should moonlight as an NI sales rep.

It sounds like "can't attain" means that your application doesn't get a response. That could easily be caused by an application error. Which is likely, seeing as how you misuse locals. Also, I noticed your Packet TR isn't opening the port or setting a baud rate. I think you need to get rid of the response ID checking and improve error handling. Ideally it would be as simple as "Open Port, create packet, wire that straight into the visa write, wait a second, get all the bytes off the port. View the bytes as hex and see if you can figure out what it's sending back." If you get a good packet back, then you know it's probably just an application error. If you get nothing back, you might want to take apart the uC and see if you can find out what pins to probe or what's going on at the serial end somehow, I guess I'd want to know what was working before. There is some chance it's a driver issue and you have to live with it. if you get back a visa error, then we can look at solving them.

I feel like USB is a bit of a red herring. It sounds like your microcontroller has a USB to serial converter on it. With real USB communication, you don't have to specify a baud rate. Here's some more info on USB raw http://digital.ni.com/public.nsf/allkb/E3A2C4FE42D7ED0D86256DB7005C65C9 When you say it can't attain 921kbaud, what do you mean? Are you getting an error code from VISA? Is it possible that the microcontroller doesn't support those baud rates?

I'm not sure you can do what you want to do with the XY express VI. You need to make an array of XY bundles as shown below.

Double click the "Build XY Graph" express VI. Uncheck clear data on each call. Also, you don't have to subtract 1080 or 720 from each x,y pair. You can just click on the top most number on an axis (eg 720) and enter in 0. That will make it so that small y values are plotted at the top.

Is there anything preventing you from moving the graphical objects around? There's some property nodes for that. As for the z-order, you can vote for that here: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Programmatic-Manipulation-of-Object-Layer-z-order/idi-p/1262886

I thought it was a bit vague in terms of what you want. You want another UI theme in addition to classic, modern, and silver, or something that's more evolutionary like NextGen?

To the rest of us out of the loop it's just spam though

How did your program exit? Did the enqueue timeout? If not, the rate is probably limited by the camera. If so, your rate is limited by your disk. Are you using a laptop? You can get an SSD for <$300. How big did you increase the queue size. If you use 64 bit labview and have tons of memory, you should be able to store all those images to memory. Actually, how are you benchmarking your frame rate? I would benchmark it in the top loop and output the delta t to a chart so you can see if it goes fast while you are using memory.

There's no advantage in the lookup case. That was just to show syntax. The advantage in the increment case is the same as with the other IPE border nodes. It provides a cleaner syntax and, if the child variant is large, it might improve performance by avoiding a copy.

The variant on the inside is referencing the child's data. The author wants to add the new attribute to the parent variant.

Here's an example of using producer consumer. If you have a solid state hard drive or a RAID disk, something like this should work. You'll notice there's two places we're storing images in memory. The "number of buffers" and the "max queue size". In this example, we'd primarily increase the max queue size to store more in "RAM". IMAQdx already decouples acquisition for you so another option (not shown) is to increase the "number of buffers". While you were saving the image (where the enqueue is now), IMAQdx would be filling the next buffer in parallel. The only caveat is that IMAQdx uses a lossy buffer so you would have to monitor buffer number out to make sure you don't miss any frames.

Your reference id: 0x496d6167 is hex ascii for "Imag". That is, it's the first four bytes of your image name. Images are string references a bit like a named queue. It's too bad Image Refs came before DVRs. It would have been much simpler to understand if you knew the DVR syntax.

Good tip! My ROI tools (just the selection and rectangle tool) still look ancient though. It's fixable but I was hoping someone else did it first.

Does anyone know of a flat style imaq image display? All the image displays from NI are either submarine colored or have dropshadows from the last decade

I'm not totally clear. You said IMAQ cast is working. Are you trying to reimplement IMAQ cast?

Looks like it could be a good solution for these ideas: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Integrate-Start-Asynchronous-Call-with-Static-VI-Reference/idi-p/3307187 http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Asynchronous-Call-By-Reference-with-Strict-Static-VI/idi-p/1662372

I'm not sure why the idea exchange mods didn't understand how powerful it is to be able to generate a case structure from a "class". The primary advantage being that you can put terminals,locals, and front panel linked property nodes in a case structure but not directly in a subVI. That can make things easier to debug because, from the front panel or from a terminal, you can "find all.." for those. I feel like they are stuck on OOP as a one size fits all solution.

The reader will be using minimal resources while it's waiting for a new message so there's no need for additional breaths. I still think you need see where the extra messages are coming from by creating very well known unique messages. Also, your error handling in the reader terminates at the RT FIFO so I don't think you're catching errors (which seems like a likely culprit at this point). You can "OR" in the error and the timeout from the read to make sure you don't go processing invalid messages.

No, from the application level, I don't know of a way to see how many elements are in the buffer. It's unusual to leave anything on the buffer with TCP. Normally, you read as fast as possible without any throttle. You can then implement your own buffer in a queue for example. Then you'd get to use the queue tools to see what's in the buffer. I think your problem points to an application issue where something's writing faster than you think or your reader isn't really reading. Maybe it's throwing an error or something. What do you think about my "unique data" idea. You could slow the server down to once a second and just send 1, then 2, then 3. You should see that show up on your client. Also, you might want to post your client code.