Jump to content

smithd

Members
  • Content Count

    739
  • Joined

  • Last visited

  • Days Won

    42

Posts posted by smithd


  1. You could also use a color box indicator behind a transparent control. Color box indicators dont need the UI thread to update, I dont think.

    to answer your question, I'm coming from an industrial control background so I'd say B. you dont need to change color faster than say 200-300 ms unless color is critical to your application, so a consistent polled update seems much easier to implement and is more stable of course


  2. theres no such thing as determinism over standard ethernet...

    I believe cdaq will automatically pack the digital lines pretty effectively, but you can just use task manager (on win10) to see the network traffic, else use resource monitor. I wouldn't suppose there is any issue with the network. In fact, I wouldn't even expect that function to be blocking for an ethernet device, but maybe it is. Does anything else happen in task manager when you see the blip? Does it still happen if directly connected?


  3. fair enough, but I guess as a bottom level statement I (perhaps misguidedly) trust windows to do a better job of cleaning up failed processes than labview to clean up dead clones. This is especially true if the workers are doing anything that isn't completely core to labview -- for example, calling 3rd party dlls (or imaq).


  4. Whining mode: I know they are your and Jeff's baby but the last time I had a small (1 VI doing some pipelined processing) greenfield opportunity to try them out they were pretty cool, seemed to work well in the dev environment (if a bit slow to do all the scripting steps) and I was excited to be using them...and then app builder happened. Quickly gave up trying to make my single VI build, tore out channels and replaced it with your other baby, and it built right away. Its unfortunate because the concept seemed to work as nicely as claimed, but...app builder. App builder truly ruins all good things 😢

    On 1/28/2020 at 7:28 PM, rharmon@sandia.gov said:

    I intend these clones to run for an extended periods of time months to maybe years.

    Helpful mode: This is a key line -- I wouldn't necessarily trust myself to write an application to run standalone for that long without any sort of memory bloat/leak or crash. My personal recommendation would actually be to spawn them up as separate processes. You can build an exe which allows multiple instances and pass parameters (like a tcp/ip port) to it. If one fails you can restart it using dotnet events or methods (or presumably win32 if you, like shaun, have an undying hatred of dotnet). You can also use a tool like NSSM to automatically restart the supervisor process (assuming windows doesn't break in this time period)


  5. Eh, I'm totally fine with security experts making it so I can't shoot myself in the foot. My main goal for my secure networking layer is to give me the most reasonably secure connection to another device without me having to know. They do have some protocols available but disabled by default (I think this includes SSL3).

    FIPS, as I understand it, is less about the algorithms and more about certification of a specific version of an implementation of the algorithm, which is then ossified and never changes even for security fixes. So to their point, its about checking a box, not providing security.


  6. On 1/18/2020 at 3:17 AM, ShaunR said:

    Although it may be easier from the User end, it's still fundamentally a port of OpenSSL but without FIPS support. LibreSSL doesn't support TLS1.3, currently, and according to their Git it's sitting at OpenSSL 1.0.1 so it will be a while before it has TLS1.3.

    Some would say avoiding FIPS is a feature :P

    And yeah, it will be a while for 1.3 -- they refused to do anything until it was actually standardized and now they are working on it. Seems like their attitude is "1.2 isn't broken yet" which makes sense. Their focus from the start was to fork openssl and clean it all up, which they seem to be making good progress on. I wouldn't have expected any correlation to the openssl version numbers at this point.


  7. libressl seems to have a better focus on stability, plus their api is much better.

    https://en.wikipedia.org/wiki/LibreSSL

    When I wrote my little tls library i wanted to avoid the dll issue so what I did was use the callback variant of the api here and here and just used the built-in labview tcp api. The callbacks are run when the library needs more data to enter or leave, so I just made the callbacks write to a queue which I then pull from to feed the labview primitives. Its a much much much nicer api than all that openssl stuff. Openssl docs make my soul cry.


  8. On 1/1/2020 at 1:36 PM, ShaunR said:

    Indeed. It does have some useful features though like congestion control targeted at small packets and discovery.

    Seems to be more performant too.

    Its important not to miss the details on that performance one. They went for the specific use case of very very underpowered devices, very infrequent sending of data, etc. For example they assume a new TCP connection for every data packet, unless I misread*, while on the DTLS/coap side they ignore security handshaking, assuming you have a factory installed pre-shared key instead. It looks like it also ignores the fact that CoAP uses a rest model, meaning a request-response cycle. If you include that information they are basically saying "UDP protocols with no reliability except a super super barebones re-transmit feature work better than TCP if you close and reopen the connection once per second"..which...yeah.

     

     

    *

    Quote

    For TCP, the session is terminated after each sensor report was received in the other end of the connection

     


  9. 13 hours ago, X___ said:

    No interest in NXG from this neck of the woods would be the feedback to the Powers that Were.

    Lol. Sorry for sidetracking, but I tried to get it to even open and it crashes on my machine. If you believe a KB, at some point someone before me installed a beta version of nxg on what is now my laptop (seems unlikely). The fix is to uninstall nxg, uninstall ni package manager, "Remove any supporting NXG files in the root directory, removing any trace of LabVIEW NXG from the machine" and reinstall everything. I asked NI support what "the root directory" is I'm supposed to delete NXG stuff from and they told me it meant the C drive 😕. Find an unspecified leftover NXG file somewhere on the C drive and delete it. What a joke.

    11 hours ago, ShaunR said:

    Hopefully TLS1.3 :D

    Lol


  10. On 12/27/2019 at 9:02 AM, Jordan Kuehn said:

    As I read the OP the question was does zeromq fill this gap in native NI offerings? I quoted a mention of some of the holes that exist and suggest that I think they still exist. Perhaps I should add some context. I remember when this conversation first popped up as well as rabbitmq. I thought that it was just an effort to include a third-party communication protocol to make rt targets able to communicate with 3rd party devices and I don't really have *that* need. However, filling some of the holes in NI offerings is something I am interested in seeing if this is the case. I work with cRIOs daily and have a working toolset, but I was curious to see where this (or other) protocols sit today in terms of the original question. If I misunderstood the OP, my apologies, and I do realize this is an old thread, but that isn't always frowned on here.

    I see, yeah I don't know of any movement on the ni side to improve data comms. Rabbit is 'available' via systemlink, but...requires systemlink. Its also just about 2020 and we don't have any secure network api built into the product.


  11. Cross post is here:

    https://forums.ni.com/t5/LabVIEW/Errror-538179-Modbus-TCP-IP/td-p/3999197/page/2?profile.language=en

    StephenD in that thread is correct. I don't have labview installed here, but the error literally just means that you are using the base class for something. The base class has no implementation, so I added an error which says "hey you just tried to do something with an uninitialized, dead base class". I added this error message because I think I had a case structure where I accidentally selected "use default if unwired" and so that case structure was returning an uninitialized parent object.

    Other situations to look for:

    • Uninitialized shift register (ie action engine) used before initialized
    • Pass object through a for loop without using shift registers -- if the for loop executes 0 times the output will be a dead parent object
    • case structures as described above
    • diagram disable structures you forgot to wire through

    You should be able to probe your code (turn on 'retain wire values') and you should see a point somewhere that the initialized object gets invalidated. Or you could put breakpoints in your action engine cases and see if one of the error cases is called prior to the modbus object being initialized.

    As a general statement I don't use action engines/fgvs because I find them to be confusing to manage, but then labview objects are also confusing to manage. The modbus master object is internally reference based and the wire can be safely branched. I would typically not do this either -- I'd have a single loop which talks to a device and is responsible for writing data to that device or reading data from that device.


  12. I don't really think the metaphor matches. Left handed scissors are obviously intended for we 10% and are marked as such. In your examples, its not clear who xctrls and ppls were designed for, nor what "using as intended" actually means.

    In contrast: left- and right-handed knives. They do this fun thing where they just steadily slide outward and make all your cuts super weird if you're using the wrong hand, but they still kinda cut so its very non-obvious. Its funny to watch, and its not really marked unless you look carefully at the edge, and you also have to know that you were supposed to look and check the edge in the first place, which many many people do not. And then if the knife slides off the edge of what you're cutting, you might just cut right into your hand. This seems like a more fitting analogy to xcontrols, myself ;)


  13. On 11/8/2019 at 5:24 AM, drjdpowell said:

    A while back I posted a beta version of a client library to access Postgresql.  The project driving that work was put on hold, and I have not done significant work since.  But at least some people have used or have considered using it, so I wanted to see how many people that is.  There has also been a desire expressed to me about using it on RT, so I wanted to know if anyone has developed it to do that.

    I've definitely used it, although we ended up going with a different db so the code never got used for real. I think I had tried it on lvrt but I can't really remember. I tend to think that talking to a central db from an rt target tends to break the nicely distributed nature of the systems and so I'm more likely to use your sqlite on rt, but I get that for test systems and the like (now that PXI RT Linux is a thing) might be more likely to talk directly to a postgres database.


  14. 17 hours ago, drjdpowell said:

    Worse, writing the image ref only triggers the need for a refresh of the control; the actual read of the data is asynchronous (like all LabVIEW indicators) and happens a short while later, possibly after the image has been changed.

    i think if you put the img display in snapshot mode its synchronous?

    On 10/4/2019 at 4:22 PM, Rolf Kalbermatter said:

    The reference nature for images is neccessary as otherwise you run out of memory very quickly when trying to process huge images.

    I agree that imaq needs refs, but why does it need named refs? Thats the part thats horrifying


  15. On 9/25/2019 at 6:35 PM, G-CODE said:

    A lot of the code under the hood just ain't that pretty and some people don't really care about that. I do so I find myself getting annoyed every time I dig into it.

    Yes, I don't really care about that, and I will use block diagram cleanup until its pried from my cold dead hands 👻

    Some of the key parts (like the engine) are relatively neat (by my standards) but due to the complexity its definitely still a hot mess. And of course a lot of the code dealing with all of the data types is scripted because aint nobody got time for that.

    Your other comments are fair though, some definite mistakes were made in the design, but all told I think it does a decent job.

    On 9/25/2019 at 8:31 PM, MarkCG said:

    My biggest gripe about it is that there is no built in events / messages/ triggers.

    Yeah, I made an aborted attempt (https://github.com/LabVIEW-DCAF/ModuleInterface/tree/StreamingAndEvents  and   https://github.com/LabVIEW-DCAF/ExecutionInterface/tree/StreamsAndEvents) but...then I left NI. The nature of labview merging is such that those branches are probably now useless :(

    edit: theres probably a few implementation-side branches too like https://github.com/LabVIEW-DCAF/StandardEngine/tree/StreamsAndEvents


  16. On 9/5/2019 at 9:21 AM, patufet_99 said:

    Hello,

    in the LabVIEW Modbus API Master example there is no error handling.

    Is there some function or method to explicitly check the status of the communication In case of communication interruption, Modbus Server restart or other modbus error,?

    Should that be done by parsing the error codes if any when one read/writes registers and then re-trying the connection?

    Thank you for your help.

     

     

    Labview doesn't provide a way to check the status of the TCP connection except by trying to use it. Serial modbus has no physical way to check the connection except by using it. In both cases you need to use it to see if it still works.

    On the master (client) side you will see any of the TCP error codes (56, 62 and 63 being the most common as I recall) for the TCP master. For serial masters, you will only ever see 56. I suppose some VISA-specific codes are also possible, like if there are parity bit errors or if you're using a usb-serial device that gets unplugged, that sort of stuff. Modbus protocol errors are - 389110  as mentioned above.

    On the slave (server) side you will never see an error from the data access methods because the access is local. You can check (via a property node, I think) on the status of all connected masters (clients) for TCP. Serial is 1-1 and has no concept of a connection, so I think it just tells you the last error to occur for the serial comms process.

×
×
  • Create New...

Important Information

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