infinitenothing

I see. You can look at the subVI to see mathematically what's happening right? It's preloading your integral. The qualitative answer is going to be more subjective and involve some hand waving but it's trying to gently take control to better handle the case where you start with your PV close to the SP and don't want the integral debt. In the case of the General PID Simulator, it's doing the right thing by going down—the stable control point is around 40% MV.

10 minutes is a really long I. I ran a simulation of your gains in the General PID simulation but I wired a constant dt to simulate it running faster and it does eventually converge. The other MV perturbations are just a consequence of Kp*(PV-SP) changing.

I'm going to be honest. Some of that stuff sounds borderline discriminatory. Maybe the person comes from a culture where a firm handshake and overstated enthusiasm isn't ideal. They might still provide a diverse perspective that will compliment your team's ability.

1,3,6, and 7 would not be very important to me. They seem very easy to teach. I guess I don't care so much about what you know as much as how you think.

Slightly related to an earlier thread: What are the different ways you can provide a stop signal to a loop and what are the advantages and disadvantages to each way.

I checked that VI and removing the type cast does not change it to a floating point because one of the other cases sets the index to a typed integer.

I wonder if that's an old school "always copy". Maybe a copy paste from other code where there wasn't a type specified in any of the cases?

If you use a 0 wait notifier it takes just as long. I was cheating when I used the notifier status function which is much faster. I think this is common to all the functions where it might wait for a message and timeout. I wonder if that's similar to a 0 ms elapsed time where it does allow the processor to sleep a little.

Most of the slowness is the occurrence (50us by itself)

This is the call by ref in question inside NI's tag channel code. I don't think that gets called unless there's a probe but, yeah, the lookup could have a small penalty.

A large part of the slowness in the pipe might be the occurrence. Just checking an occurrence for 0 ms takes 50us. If backing this into 2015 would be useful I can probably do that. I skipped RT FIFOs because I couldn't see a way to use them as a global (Preview Queue) The high speed stream is more akin to queues than a tag or a global and I got an error 1055 when I tried to create it in RT Many of my loops in RT are something like "grab data, send data, wait, repeat until something catastrophic happens and then cleanup." There really isn't any "in band" communication to tag onto.

To focus on the vi being benchmarked, I put a for loop in the sequence structure: DVR:2.4us Pipe:77us Notifier:2.2us Queue:2.0us Global: 0.04us

I was considering migrating to tag channels as a stop signal and wanted to do a performance test. I'm targeting an SB9627. I've attached the bench marking code below. Results: DVR:8.3us Global: 4.1us Notifier: 7.9us Pipe: 90us Queue: 7.7us I'd say all the reference based methods are about the same. The global is the fastest but there's potential reuse issues. The pipe is significantly slower.

In my example I was trying to show that the for loop (which could be made a subVI) took a long time but the individual iterations of the for loop were relatively fast. I was more curious about what other people have done because I almost never use the queue status VI. The "abort" option does sound clunky. There wouldn't be a way for the SubVI to perform post cleanup operations

Is this a good way to stop a calculation midstream if you get a new input?

Expansion chassis node? See the bottom of this: http://www.ni.com/white-paper/10555/en/

I use RT a lot and actually haven't run into this much. Most of the time the only thing I share between the RT and Main are the control type defs and normally, when it blocks me from editing, I like that reminder. I just stop my RT code. A stop button is about the only thing I have on the top level front panel out there. I almost never edit things in libraries on the RT side. I was probably trained out of it. The RT code is usually fairly light and doesn't do fancy stuff for performance reasons. It's somewhat old school programming. On the Windows side I'm less concerned about memory so I'll let my data types get heavier and I'm more willing to create new threads.

Ask the developer for the source code

IMHO, we've talked about it before and this is the annoying part of the license: We talked about making a tool that would collect all the providers but it seems unnecessary for compiled code. In some cases, maybe its undesirable to let others know what your tool chain is.

What if the client computers pushed the files onto the top level computer rather than having the top level pull? That's a similar concept to a database but not quite as well organized. Like I said, it's really easy to move from a sequential for loop to a parallel for loop. I'd experiment with both. The Async is what lets "other things" happen.

Sounds like you're going to want to launch the background VIs with Start Asynchronous Call. You might not want to launch 10. Maybe just loop through the 10 computers in a for loop. This is especially true if your top level computer is using a magnetic disk drive. You could try and switch the for loop to a parallel for loop later. I'm not sure what your file goals are, it's sort of an unusual use case and maybe setting up some sort of server on the top level computer possibly a database might be the way to go. You're probably going to want to go through the folders recursively unless it's a flat folder. Maybe you can look at timestamps to see what's modified.

I don't think your for loop will work because it's in a SCTL and it has the FIFO in there. You have to give up one of those. That is, put the for loop in a normal loop (pass data between the loops using a local) or remove the for loop and keep an index on a shift register in your SCTL. Also, your select function does nothing, you can just delete it and wire the boolean through. I'm not sure how that API implements write-read. I think you just need to enter your byte array sequence that specifies the register in the write array and set the read Boolean to false. If you have trouble, maybe ask the authors of the API. The shared variable is written so if the loop exits because of an error, the other loops are notified and stop. FYI, there's an specific forum for embedded questions you can use.

The secret is that the incoming error is always the same as the outgoing error. Grab it where it's more convenient but you don't need both. If you need the warning, and I never do, you can merge it at the top on your rightmost merge. Reference: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Can-we-have-an-error-in-terminal-on-the-in-place-element/idi-p/2008551

Use a second Ethernet port on the host for the CRIO. Password protect the RIO. Shut off features I don't use.

Keep Windows up to date Install antivirus Windows is logged in as normal user, not admin Firewall off everything you don't need Use a VPN to get into local networks If I had to expose a service I'd use HTTPS