Jump to content

infinitenothing

Members
  • Posts

    354
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by infinitenothing

  1. 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
  2. Functional globals are the first thing that comes to mind. If you wire it, you want it to store the input. If you don't wire it, you definitely don't want it to store the default value.
  3. 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.
  4. There's a training course: http://sine.ni.com/tacs/app/overview/p/ap/of/lang/en/pg/1/sn/n24:14963/id/1587/
  5. I'd much prefer to get to the root cause of the issue than to try to buffer my own retry. I just don't have enough experience troubleshooting network issues to know how to isolate that sort of problem
  6. 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)
  7. OK=True seems more failsafe because if you do something stupid like have a zero itteration for loop it'll output false and usually doing nothing is safer.
  8. 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.
  9. 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. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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?
  16. 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.
  17. Most of the slowness is the occurrence (50us by itself)
  18. 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.
  19. 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.
  20. 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
  21. 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.
  22. 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
  23. Is this a good way to stop a calculation midstream if you get a new input?
  24. Expansion chassis node? See the bottom of this: http://www.ni.com/white-paper/10555/en/
  25. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.