Jump to content

ShaunR

Members
  • Content Count

    3,903
  • Joined

  • Last visited

  • Days Won

    195

Everything posted by ShaunR

  1. Is that being done inside the DLL functions, rather than in the LabVIEW code? I don't see any checks in the LabVIEW code. Nor do I see the CRC being passed to a DLL function.
  2. Yes. The only way to guarantee that LabVIEW does not use multiple threads is to use the root loop. Unfortunately that is the same thread that the UI runs in for certain tasks (we all know not to use the native dialogues, for example). Under normal conditions, LabVIEW has a thread pool (sometimes a couple of hundred threads) that it uses and there is no control over which threads in that pool it will use to call a DLL. If the DLL is thread safe then you can choose "Run in Any Thread" and LabVIEW will use whichever thread it deems fit at the time to call the DLL and the DLL is assumed to handle thread locking. If it is not thread safe, then you must select "Run In UI Thread" so that it is always called by the root loop thread (there is only one single thread there). The easiest analogy to think about it in LabVIEW terms is that when you select "Run in Any Thread", the DLL is behaving like a reentrant clone with the setting "share clones between instancies". You will no doubt be aware that strange results can occur if the reentrant clone with this setting has a shift register as memory inside (akin to your DLLs global). The reason for that behaviour is because you cannot guarantee which which clone, in which order, is used so the state of the internal memory, is unclear. You obviously don't get a crash when that happens, just strange results but in a DLL you'll get deadlocks, crashes and an assortment of bad behaviour - especially if pointers are involved. The way to get around it in the LabVIEW example is to run it either as a "Preallocate For Each Instance" or a normal, non-reentrant VI. The former is not an available option for DLLs. The latter is the equivalent of setting the DLL to "Run in UI Thread".
  3. Unless the DLL is thread safe (which you have said it's not) you must run it inthe root loop (AKA single threaded).
  4. You are running it in the root loop (Orange Node), rather than run in any thread. right?
  5. I was actually working in 2013 at the time but have just checked 2018 and it is indeed in there. So it was obviously added after 2013.
  6. I know. You obviously didn't get the dig at a keyboard warrior vs a mouse clicky, coffee in hand, reclined on the sofa, coder layabout like me
  7. IC. I'll have a play around with the XML now that you have shown me how to do it (many thanks). Maybe I'm just being a bit OCD about it but once/if it's done, I won't have to revisit it anytime soon.
  8. Many thanks. I thought that might be an issue. I can move it around using a property node (if I scan the FP objects to get a reference). Like you said. You can't select it (not that you can with the vanilla splitter either) which means you can't create property nodes either so scripting would be the only way of doing anything. Is it possible to make it 1px in edit and 0 in run modes? I've no idea how these controls are put together but xcontrols can be different in run or edit.
  9. Yes. If you can get rid of the gaps created by the splitter and array border (marked in red on the second image), that'd be great.
  10. The picture control is just what I'm looking for (thanks Hooovahh). that eliminates the gap between elements The array border and the splitter wouldmake it perfect
  11. I'd be interested in a 1px border array and/or picture control if you're hacking them. The element separation on an array control is huge and annoying. Oooh. And a 0px separator or can make it transparent
  12. Yeah mine were a little more obvious that an xcontrol was really the only elegant half-way decent solution. One was a string control with markup and the other was a tab control that works like the native one should. So it was really about encapsulation.
  13. If that scares you then I don't give you good odds on "fixing" the LabVIEW source when it's released I've just written two XControls. (First time in about 6 years). They seem to be ok but some of the ways they work can be a bit unintuitive.
  14. Surely it would have been easier to just add the CRC check in the openG.
  15. When you edit a palette set, there is an option of "Place VI Contents" when right clicking on a VI, which will drop the code contained in the VI rather than the VI itself (like a template). Maybe it has something to do with that.
  16. That only tells you if the bytestream has been modified in transit rather than if there is a corruption in the archive itself.
  17. Well. Rold is particularly thorough, so In the interim. If it's windows only, you could try Zlib Library for LabVIEW 1.1.0 It has a compatible VI with the native LabVIEW but I didn't notice the conpane for the OpenG ones. I'd be interseted if it passed your tests too.
  18. Actors? (AKA Throwing lots of cats in the air then trying to herd them.)
  19. If you've ever started up Wireshark, you'll see occasional TCP retransmits due to differnet factors - especially under load and especially with Wifi.. These don't get retransmitted with UDP. It sounds like most of your losses was were due to packet collisions.
  20. I don't see a check in there at all. It's not much of a change in the bowels of the LabVIEW code, but does require a new CLFN to call the CRC which fortunately does exist in the DLL.
  21. Itseems to me that that this is an extremely poor cure of the symptom rather than addressing problem. If it ever gets deployed somewhere other than your particular network, with your particular data needs; it will undoubtably run into problems. RUDP is an application overlay. So you would need to code it yourself (from the spec I linked to). I don't know of any LabVIEW implementations but there are quite a few similar ones (RTP?) since UDP is used all the time with VOIP and video streaming.
  22. ARP is part of address discovery. It links MAC addresses to IP addresses. Yes you do need it. Ditto gleichman or implementing something like RUDP at the application level.
×
×
  • Create New...

Important Information

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