Jordan Kuehn

Your VI is missing a subVI so I cannot run it, but you will likely need to use the two derivatives together. The zero crossings of the second derivative will give you the points of inflection as ShaunR pointed out. Use these locations/indices to reference points on the original function and the first derivative. You can likely filter out your segments by looking at the first derivative values and determine which points of inflection are important or are on your curved segement. The value of the first derivative at that point will give you your slope for the tangent line.

Some context. Possible Dup. https://lavag.org/topic/18676-signal-analysis-and-processing/

With minimal modbus experience you should realize that you will need to both configure the Kolmorgen drive to expose and react to the data in the modbus registers and program the LabVIEW code to interact with the drive. Additionally, you are best off using the built in modbus tools in LabVIEW now that require the DSC Module or the RT Module. That said, you can probably accomplish what you need using a low level API that is not officially supported. This will take more work and understanding of the modbus protocol, but is cheaper if you don't have either of those modules. Finally, take into consideration that it is not a very fast protocol and will perform more slowly the more registers you need to access.

I was contacted by our ISR (I think that's still the title) a week ago or so, encountered the same problem, was forwarded to support, and nothing since.

Try encasing the column name in double quotes "user" and using the original query with the = comparitor and the semicolon. postgresql test.vi

Does postgresql require a semicolon at the end of the query?

We have developed a Modbus based control system for a Kollmorgen drive for a customer. It works well and uses ethernet connectivity. I would suggest investigating that to see if it meets your needs based on timing requirements and the control variables that are exposed in the modbus registers.

I apologize, select grayscale. The important part is to have a separate reference, from glancing at your code.

Did you attempt what I suggested?

Create a new binary image outside the loop and feed that output as the destination for the output of your vision assistant processing. That should stop the final image from flickering, I think this is what you are complaining about on the output. Image wires are references, not values. The area particle measurement should get you the value you want. What is wrong with that?

In my opinion, yes. Otherwise you risk breaking compatibility with existing implementations.

If it retained the current functionality and added the ability to parse those additional parameters I think it would be a useful addition.

If you consider this as similar to Matlab array indexing, then I believe it should be inclusive. And there's an answer to #2. http://www.mathworks.com/help/matlab/learn_matlab/array-indexing.html?requestedDomain=www.mathworks.com

It is better today. I tried a few things, but nothing helped at the time.

LabVIEW has been marketed as a complete language since at least 2009. It should be able to stand up to python and such. That said, it's not just NI that is responsible for driving acceptance of the language and moving it out of the niche space. We (professionals, but definitely consultants) are a big factor in driving that as well. Initial costs to develop a system provide a lot of inertia after it is completed.

Awesome. Sorry I didn't get around to advancing things like I had hoped! I will try to look through this and your new goals to see what I can add if I have a chance.

Hmm. I still see it today.

^

I have had some good experiences with Agilent power supplies in the past. Most of them were GPIB, but they have some USB controlled ones as well.

That's an interesting question. I'm not sure how I originally found Lava years ago. Probably a google search result since the NI.com search is/was terrible.

Nice. 1996...

Agreed, DSC should stand on its own for customers that need a SCADA system. I would be willing to bet the vast majority of people using NSV Events have no need for anything else in the DSC Module. At the very least give us a runtime that is free and only has the NSV Events. Thanks for the links! That looks like it would work, but requires a significant investment in time as well as using CVI...

I know this thread is a bit old, but relevant to my question. I'm essentially asking the same question that MatthewHarrison asked at the end regarding shared variable events without the DSC module. One twist, I've once made this work via bound front panel controls and registering for a value change event of that control. This was in LV2014. Now I'm looking to do it again with another customer that doesn't want to pay for DSC and it's not working in LV2015SP1. Does anyone have any input on getting this to work in either environment?

What it you broke the section into 2 sub-fora? One designed for Q&A and the other for discussion. The line is a little blurry, but most people can tell if their post will incite more of one or the other.

Is it possible to have the thread author choose?