infinitenothing

No, it will break if you try and convert a U8 into U16 so it's a little conservative in that manner.  The programmer would be expected to do the U8 to U16 upstream to "get rid of the broken arrow". It would be really cool if there was a way to allow all the "safe cooerces".

Coerce to type is useful for getting nontypedeffed data into a typedef form but there's a small problem of type safety. For example, if you try and coerce an I32 to a U8, the value will silently wrap without even so much as a coercion dot.

But in recent versions of LV, we have something to ensure a little safety— "Assert Structural Type Match"

And fortunately, for this use case, it's not so sensitive as to disallow typedeffed data from matching it's plain counterpart so we can use it to enforce a runtime error if someone wires an I32 up. And, to make this new function more convenient, you can wrap it up in a VIM. 

Search the downloads page on their site or try this:

http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/sn/ssnav:dwl/q/vivado/

Cross posted:

https://forums.ni.com/t5/Real-Time-Measurement-and/LabVIEW-2018-and-SbRIO-9626/td-p/3830776

No, by current spec I mean:

Quote

±16 mA all channels maximum; ±4 mA per channel typical

 

By "how are you connecting", I meant connecting to the analog side of the module. For example do you have one of these: http://sine.ni.com/nips/cds/view/p/lang/en/nid/210164

I see that you have the module setup for differential, that's a little more tricky right? Can you try single ended? maybe with a battery or a potentiometer. Otherwise you have to watch out for things like common mode voltages and such.

Many people use variant attributes for trees.

I'm a little curious about your time sensitive use cases, it almost sounds like you want a sorted list instead of a tree which, I think there are some examples of using maleables in 2018. 

I think being able to use variants in the in place structure may have opened some doors:

This is pre 2012 but it's a implementation of some data structures using DVRs and OOP

I assume you've configured the 9205 for single ended vs differential correctly?

Are you within the current spec of the 9264?

How are you connecting the modules? A cable or one of NI's breakout boards?

Try and simplify things as much as possible. For example, use a battery as a voltage source directly to the input and disconnect the outputs to rule out loading issues.

Does this only affect users that get updates from the repositories? because that seems like a fairly small minority.

If you make an idea on the exchange, I'll vote for it.

I made a snippet to illustrate what I was thinking. I have a Basler dart camera that I was able to test with and it looked OK in theory. You'll notice it is in continuous mode. I'm hoping that since trigger and the exposure both go through property nodes, the settings will apply in that order. There might be a theoretical race condition that would apply the new exposure to a capture in progress, I guess for that, you could capture the exposure before and after and have some sort of indeterminate case but I think it would be nearly impossible.

Many cameras have a soft trigger function. Maybe you could count images vs soft triggers before the exposure change to figure out the exposure of each image.

OK, I'm hearing overwhelming support for a web interface. Is anyone familiar with existing test data web services? I'm surprised I don't hear about this more often.

Lacking other input, I'll probably try and go with a django server since I like its database coupling.

How about this:

I'd like it if my test stations sent their test results to a web server. I'm wondering if anyone has done this. As I see it, I can probably do some port forwarding and expose a Maria/MySQL database over the internet or I could give that database a thin web interface and send the data over PUSH http requests. Are there pro/cons to one over the other? TLS is an option for either. Do you think HTTP would be more firewall friendly?

It's always a project by project decision for me. If I need the flexibility, I'll go TS. Otherwise, it's not worth the deployment licensing hassle.

Another advantage to rolling your own is you get to use LabVIEW's block diagram representation of the sequence. It's a great visual—things in parallel execute in parallel. Data flows on wires. What can I say?

FYI, regarding FP locking in event case: http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/lock_fp/

Everything in the loop must complete before it can run again. Therefore, if the case structure is in the same loop as an event structure, they have a relationship and aren't really independent.

1 hour ago, ShaunR said:

The NI-9219 has a programmable constant current source and +-25mA is the range, isn't it?. The examples show a default excitation current of 50 or 100uA. I don't know what the resolution is off hand so don't know if it can go down to 10uA, though.

No not programmable

Quote

Excitation level is a characteristic and is not software-selectable

I've never had a problem with self heating but I've always had really good dissipation. I think if you need a lower current, you can use the half bridge method others linked to or a programmable current source like the 9265 with a second analog input module.

Why do you say the current would be too high with a 9219? The user manual say it would apply 2.2V which would be 400uA.

I guess if you wanted a lower current you could get a current source module and measure the resulting voltage with an analog input card to get resistance.

Try right clicking, saving the image to disk, and then drag the saved file from explorer to your block diagram. The snippet is in 2017 so if you need an earlier version you might have to ask someone to down convert it or... there's not that many blocks there, maybe you can try and recreate it.

I guess this is a "what's new in LV" thread now. There are some performance improvements in the conditional indexing tunnels on a for loop. I think it allocates the max size and trims it at the end. The async tools are also a huge performance increase over the old VI server method. Also, DVRs now allow parallel read access which is cool. The menu plugins provided many productivity improvements. VIMs make reuse easier.

Regarding the new dynamic refnum behavior, does everyone agree that the right terminal is more or less obsolete and could probably be replaced with something like a linked tunnel? Am I misunderstanding the new behavior?

Even VI server is going to have some drawbacks like accessing latching booleans and whatnot. If anyone has and idea exchange post in support of automated GUI test, I'd kudos it.

My example uses the second technique (subtracting a constant at IMAQ Subtract). Where are you getting these requirements from?

Also, it's nice if you let us know where you've cross posted this so we don't duplicate efforts

https://forums.ni.com/t5/LabVIEW/calculate-1-e-2-of-beam-intensity-profile-Measurement/td-p/3766062/page/2

https://forums.ni.com/t5/LabVIEW/Background-correction-and-Normalizing-Image/m-p/3766148#M1060967

That's a snippet so in theory, you should be able to just drag it into your block diagram negating the need for a VI file

Something like this?