infinitenothing
Members-
Posts
354 -
Joined
-
Last visited
-
Days Won
15
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by infinitenothing
-
Area within a curve - Green / Kelvin-Stokes Theorem
infinitenothing replied to gyc's topic in LabVIEW General
How accurate do you have to be? Maybe implement your own flood fill? Otherwise, you have to define some sort of point to point interpolation which could be as simple as defining a polygon -
Since it's a 1:1 connection, I'm hoping that disconnects are infrequent enough that in the rare instance that there's a disconnect I can just let the user click a "reconnect" button when it happens. Of course to get to that point, I need to rule out as many possible causes of disconnects (application, OS, etc) as possible which brought me here. Buffering on the server is something I'm very nervous about. It's a fairly dense data stream and it would pile up quickly or could cause CPU starvation issues if implemented wrong. All this makes me appreciate NI's Network Streams. I just wish there was an open source library for the client.
-
There's a training course: http://sine.ni.com/tacs/app/overview/p/ap/of/lang/en/pg/1/sn/n24:14963/id/1587/
-
I'm debugging an issue where the server and client communicate fine for a long period of time but suddenly the server and client stop talking. Eventually the server (LabVIEW Linux RT) starts seeing error 56 on send and then 15 minutes later, the server's read will see error 66. The client is running on windows (not programmed in LabVIEW) and we can run diagnostics like Wireshark there. It's a 1:1 connection. Is there a way to gather more info as to why a TCP connection fails? Example be able to tell if: Client closed connection (normal disconnect) Some one pulled the cable (can blame user) Client thread crashes (can blame client developer)
-
It looks like NI is using option 5 on the wiki page. You could implement #3 manually which maybe gets you closer to the second screenshot. You seem to like option #4. It would be interesting learning the pros and cons of 4 vs 5. Maybe an enum selector input would be a nice feature. I was referring to the initial drop below 100 in the first screenshot. I was saying it was desirable for when your PV was close to your SP but you still needed output.
-
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 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?
-
Boolean Tag Channel vs Notifier Performance
infinitenothing replied to infinitenothing's topic in LabVIEW General
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. -
Boolean Tag Channel vs Notifier Performance
infinitenothing replied to infinitenothing's topic in LabVIEW General
Most of the slowness is the occurrence (50us by itself) -
Boolean Tag Channel vs Notifier Performance
infinitenothing replied to infinitenothing's topic in LabVIEW General
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. -
Boolean Tag Channel vs Notifier Performance
infinitenothing replied to infinitenothing's topic in LabVIEW General
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. -
Boolean Tag Channel vs Notifier Performance
infinitenothing replied to infinitenothing's topic in LabVIEW General
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
-
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.