Jump to content

ShaunR

Members
  • Content Count

    4,137
  • Joined

  • Days Won

    217

Everything posted by ShaunR

  1. You have obviously never done Agile Development proper then since it is an iterative process which starts with the design step just after requirements acquisition. It's not a fear of failure, it is a fast-track route to failure which usually ends up with the software growing like a furry mold. But anyway. It's your baby. You know best. Good luck :)
  2. Uhuh. Seat-of-your pants design; the fastest way to project failure.
  3. This is the standard way to do service discovery. My "Dispatcher" implementation had a "broker" that ran on the local machine to act as a gateway to services that registered with it on that machine. External (or local) clients would then contact it to discover services and it would hand off comms to the service for direct communication. It behaved as a router rather than the usual broker and meant it didn't become a bottleneck for high speed transfers. Your framework would be a good match for the above implementation since it already has all the publish, subscribe and routing feature
  4. That's fine. I just don't like to distribute modified software that I produce where the licencing isn't explicit - which is why I asked you for one (thinking you had produced it as the original author).
  5. OK. I've deleted the backport since the licence is indeterminate. I thought it was a library you had created.
  6. Backported to LV2009. what's the licencing for this? Edit. Removed software due to indeterminate licencing.
  7. The major use case for UDP I would have is for COAPS (which, incidentally, has service discovery rather than node discovery). Most node discovery methods require a known entry point (gateway, router, default port etc) and it's hard to get away from that that in a reliable way across numerous network architectures.
  8. Very hard to do but can be done-non trivial. You will obviously have to talk to your client and find out exactly what they mean - get one of the USB sticks they use . Maybe you'll be lucky and they just mean using the LabVIEW application as the windows shell, which I do on production-line machines.
  9. It's a compromise between convenience and security and partially solves the "trust" issue by having really, really trustworthy organisations There have been other alternatives proposed but the "trust" issue has never really been solved adequately, to date. I trust me so my certificates are great (for me). The problem with that is then distribution. SSH. which is arguably the progenitor of modern TLS, got a lot of things very right. We haven't really moved on from that model except to make a whole new business sector for the key management.
  10. I don't think there is anything off-the-shelf, to my knowledge - Bluetooth has it's own encryption scheme. I think you are looking at using some existing TLS client/server implementation and replacing the underlying Socket connection with a Bluetooth connection. Edit: Thinking a little more. there may be another way. the caveat would be it would only work for RSA certs in this scenario, There is an example of RSA Encrytion/Decryption. You could load an x509 cert, extract the keys and use the encryption functions to encrypt the bluetooth data. This wouldn't hand
  11. You can't outsource security If you understand that all TLS communications are interceptable by governments because of CA's, then you might also be reticent when dealing with some governments.
  12. Congratulations. It will go great and it's a fantastic area to grow into. You won't regret it but i very much doubt you will be back at NI - it'd be a step backwards.
  13. I wouldn't. HTTPS is just one protocol. I personally use secure websockets which is much better suited to this sort of thing IMO, Most of these use TLS though and more recently I've been playing with DTLS. If I don't use those sorts of protocols then I use SSH but that's nothing to do with what the OP is asking as it doesn't use X.509 certs (which is,as you know, just a standardised certificate format). I think that's just middle-management phrasing. I wouldn't be surprised if the device already supports this method of updating and they were told it uses X.509 certificates "for securi
  14. This is quite a common requirement nowadays, especially within the IoT sphere. Many embedded devices come with libraries for what is called OTA (Over The Air). A multitude of devices are then monitored and configured (including software/firmware updates) via a web server. I wouldn't be surprised if the NI Systemlink uses something similar (via either HTTPS or MQTT). TLS is quite burdensome for constrained devices, specially if you have to put a webserver on the device to upload rather than using OTA libraries. To be honest. This isn't something I would use LabVIEW for. There are mu
  15. You will have to re-architect that if you want to.... By the way. The TCPIP I described earlier is a layer to break cohesion - meaning that the VI's can be controlled by anything, in any language, including Test Stand. So if you want the "on demand" aspect, then that is probably the easiest way forward.
  16. Another thing I did with the aforementioned was to add TCPIP (a later version). It meant you could launch a VI and then communicate with it via strings sent from Test stand - even on remote machines. The wrapper was only slightly more complex than the pure launcher but it meant you could configure the devices on-the-fly, abort or reset devices and query state information with simple strings from Test Stand (I used SCPI-like commands). Anyway. I diverge. You've probably guessed by now that the choice you had was to have an instance per device which you control and sequence from TS, wh
  17. A very complicated reporting tool. Some things are better for scripting/sequencing than others. Take the step response of an oven, for example. You need to step change the setpoint (SP) and monitor the temperature until a certain value has been achieved as it changes and note the time taken. To determine whether it has finished it's step, you detect the plateau in rate of change. In an application this is trivial and the test time is the time it takes to achieve get within +-% for n secs of SP or when dtemp/dt < x for n points (depends on specification). It is usually also monitored to
  18. The trivial answer is the launcher can be run re-entrant so you can run it from multiple scripts with different configurations etc But what you are trying to achieve, from your description, is a poor fit for Test Stand, period. So I expect there will be other things that that perhaps you haven't mentioned (like the background tasks) that will make it difficult to use from Test Stand regardless of the solution. It sounds like you really need an entire application rather than a simple Test Stand integration.
  19. What about VIRefPrepNativeCall and VIRefFinishNativeCall? They sound interesting but maybe a red herring.
  20. I wrote a simple "connector" for test stand a few years ago. It was just a VI launcher which had a standard calling convention (from Test Stand for configuration of the called VI) and a standard output back to Test Stand. It would call any VI with the appropriate FP connectors, dynamically, with parameters supplied from Test Stand. You could call any VI's (DVM, Frequency generators etc) which were wrapped in a normalising VI which created a standard interface for the launcher to call and formatted data to the standard format to be returned. All configuration, reporting and execution was
  21. This is sweet. I think we can use this information to create LabVIEW callbacks for C/C++ functions like we do with .NET.
  22. SQLite does not support concurrent writes.
  23. That's because it is, to all intents and purposes, an internal restructuring (possibly a political one) and the outward effects aren't tangible or possibly even unknown.
×
×
  • Create New...

Important Information

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