Jump to content

Jordan Kuehn

Members
  • Posts

    661
  • Joined

  • Last visited

  • Days Won

    20

Posts posted by Jordan Kuehn

  1. Is your HMI a PC running LabVIEW or is it something else? If the former, you can certainly use Network Shared Variables and get quite a lot accomplished. Especially if you just intend to expose the data to the host code and let it handle the logic and controls directly. You can also look at network streams if you want lossless communication, and/or to pass command/responses. 

    If not LabVIEW then you'll need to look at the protocols it supports and make a determination regarding where you want the logic parts to live. I typically find myself wanting to put as much in the cRIO as possible and keep the UI pretty thin/lightweight, especially if I want to have multiple UIs for the same device.

  2. One big upside to the Enterprise version that I can see would be the High Availability feature as a result of the Kubernetes clusters. I'm no IT expert, but with what I know about this it seems like a very good choice to break the various components into individual clusters and allow for individually scaling them out as well as redundancy.

  3. 21 hours ago, ASTDan said:

    Speaking for myself NI connect without community presentations isn't that interesting.   

    I would augment that with "...without community presentations OR (many) R&D presentations...". I went to several and almost all were of the Marketing variety of NI presentations, while I think there was just the one from AQ on Interfaces that I felt was really valuable. I do like the exposure to new products, but I get the most value from the advanced software presentations that R&D brings as well as the community presentations.

  4. 17 minutes ago, JKSH said:

    To be clear: That NIWeek 2019 video doesn't contain any SystemLink at all.

    SystemLink asks us to use its integrated 3rd-party user management tools, not to implement our own. In other words, SystemLink doesn't want us to follow that video!

    I agree (and NI agrees) with y'all that we should not be rolling our own user management system. (This applies to all software, no matter what price it is)

    At risk of derailing this thread, where is the documentation for these methods? I'm aware of local windows users and LDAP. Further, you do rightly point out the difference between systemlink and webvis. My conflation is due to wanting to utilize systemlink *and* webvis to serve data and dashboards to customers utilizing the same authentication method. As noted above the workspaces have issues with filtering properly using the system filter. I am only aware of workspaces as the ability to segment out accessibility of systems to users and even then I may want to limit data views via certain dates (system is on rent with different customers at different times), but that is another can of worms.

    • Like 1
  5. 11 hours ago, JKSH said:

    Currently, non-Enterprise SystemLink does use LDAP and Windows Active Directory for user management, which is good. I haven't looked closely at what new technologies are available under Enterprise (Jordan mentioned OAuth?)

    I may have misheard/misspoken here, but I thought they mentioned more open authentication methods/user management. 

     

    5 hours ago, Mads said:

     

    We do not want to roll our own, so we want SystemLink to handle it. And if NI does not want to roll their own - they can always use subcomponents that does, but to us as a user of SystemLink it would/should appear to be handled by SystemLink😉.

    In our case the bulk of the users would be external clients and we would not want to handle their dashboard accounts in Active Directory...typically the user management would be handled by support engineers that would not have admin-access to AD.

    I see some of these issues mentioned in the latest release note though. Perhaps it is time to have a closer look again.

    Agreed strongly with this. With the price tag SL commands I shouldn't be making my own user management. Which is partially why I haven't implemented the method in the video I linked.

  6. 28 minutes ago, Mads said:

    The presentation seems to show that we need to implement custom user account handling...(helpful in that regard, although just browsing quickly through the video it does not seem to be a particularly secure method - sending user names and passwords(perhaps I overlooked an underlying encryption?). What we were hoping for, as far as I remember now, was that that the user account administration and logon was handled securely by SystemLink itself, and that the selection of dashboards and/or what data those had access to would then depend on the user account (then only the last part might require the G-code to know anything about the user).

    I too would like something native like this. We have dashboards that we use internally that customers would also use, but there is no built in method to segment that out best I can tell. The system filter doesn't respect workspaces either (shameless idea exchange plug) which would be one potential workaround. I do recall seeing some OAuth options on a slide (ETA: see the last slide I posted above) for the enterprise version which would be a step in the right direction. I had that presentation in my recent memory because I have it somewhere in the queue of items to try when implementing a customer facing dashboard.

  7. 5 hours ago, Mads said:

    Regarding Systemlink for Enterprises; when SystemLink came out we wanted to use the WebVI-option to provide external users/groups dashboards offering data only that user had access to. So we needed programmatic access to the user information to then only present the dashboards/data that that user should be able to see, but that was not readily available. Managing such a setup was not practical then (we wanted to just be able to create user accounts, add them to a user group and then that user would automatically (no further programming etc needed) get access to the right data only).

    Has there been any movement in such a direction (Enterprise?), or would you still need to have separate system link servers to ensure restricted access / user specific content?

    I think this presentation from NIWeek 2019 may be on point here:
     

     

    • Like 1
  8. Job Details

    Description

     

    Software Engineer

    What is a Software Engineer?
    The Software Engineer is responsible for maintenance and development of software that is core to our Freedom Series Completion System. The ideal candidate will have demonstrable software programming capability (specifically in LabVIEW), control systems experience, mechanical aptitude, ability to direct others, and an ability to operate in a fast-paced environment.

    This position can be located anywhere in the United States but will require some travel to Oklahoma City at the beginning of the position, and then as needed potentially for a few days to a week each month.

     

    Job Listing Here

  9. 2 hours ago, drjdpowell said:

    Two suggestions:

    1) Consider using JSON as your config-data format, rather than clusters.  Using JSONtext to manipulate JSON will be faster than using OpenG tools to manipulate clusters.  

    2) Programmatically get an array of references to all your config-window controls and register a single Event case for Value Change of any one of them.  Then use their (hidden) labels to encode what config item they set.  For example, your control with the caption "Baud Rate" could have the hidden label "$.Serial Settings.Baud Rate" which is the JSONpath to set in your config JSON (or config clusters).

    This is brilliant. I imagine it could even become a standalone toolkit/extension of JSONtext.

  10. 1 hour ago, FixedWire said:

    Of course I get that you need an SSP, darn good thing I'm paid up until August...and I never got the media.

    Looks like somebody didn't tie their shoe laces.

    image.png

    We have gotten "media" recently. It took a few weeks and they mailed a piece of paper with a serial number on it.

  11. I think Mads method will work. I think it's frowned on, but probably the most straightforward. Alternatively you could figure out what permissions are set on the script file and required for the operations it calls, then make all of those executable by the lvuser. All of this is annoying enough in linux, but then Linux RT user permissions and file permissions are even more complicated than usual as some permissions are reset on boot.

    This pdf is a good reference and I think is still valid despite its age.

    https://www.ni.com/pdf/support/us/ni_linux_real-time_security_user_guide.pdf

  12. With packages you can include files (e.g. an installer), and put them where you want them. You can also call post-install scripts. I think if there is a way to call the installer silently from the CLI you could script this. You are starting to tread on IT's world though, but sometimes you need to get it done and for it to work so perhaps you are best off doing it yourself this way :D Seriously though if they have the systems in a domain or something they might be able to handle the environment setup independently of your NI packages.

    • Like 1
  13. 1 hour ago, Rolf Kalbermatter said:

    It almost feels like it was mostly about buying up competition than any specific long term strategy to build something out of it.

    Isn't this the case with many acquisitions by NI? Buy it up and let it languish instead of developing or integrating it?

  14. Cross posted to the dark side.

    Hello,

    I'm attempting to work with the launch remote actor function utilizing two cRIOs. I have a working AF application on one cRIO and I would like to spawn a few Actors to run on another one beneath my original top level actor, hoping that the top level actor will be able to interact with them as if they exist locally. 

     

    I have watched this presentation from JustACS and have considered using the nested endpoints, but this approach seems more "AF-ish" and doesn't require extra communication actors mid-tree, or mid -> top of tree. 

     

    My question at this point is that I don't think I have the dependency injection correct for a built exe. The example doesn't seem to address applications outside the IDE either. I believe I have gotten the VI Server settings working and can launch the actor from the Server side without errors now. I encountered some errors while working on the dependency injection. Note: these are built and deployed startup exes.

     

    I first started with something like in the webcast:

     

    jordankuehnsef_0-1650400792330.png

     

    And here is mine:

     

    jordankuehnsef_1-1650400829202.png

    However, I encountered errors on the Server side in the upper proxy vi until I added this loop:

     

    jordankuehnsef_2-1650400879050.png

    Now the Server side launches, but I don't see any activity from my remote actors. I expect at the very least to have some of the initial logging that happens at the beginning of their Actor Cores happen, even if there are other errors, but I see nothing on the Client side.

     

    Am I missing something simple here on the dependency injection? I attempted to include just a few actors at first, and then added all the actors that could possibly be linked in some way, added subvis to the always include in the build spec, etc.

     

    Any help or pointers here would be greatly appreciated.

     

    Thank you!

  15. I use this on cRIO with the system exec vi:

    timeout 0.1 ping -c1 127.0.0.1

    Replace the 0.1 with the time you want (s) and the 127.0.0.1 with whatever IP address or hostname you want. I use this to determine if I want to attempt to open a shared variable connection to an expansion chassis since the timeouts on that API do not work.

  16. I agree with ShaunR. Despite it being posted as replies to several posts all in one day, I don't think it's overly spammy and they were mostly relevant to the discussions at hand. It was enough to get me to poke around at the product page and file it away in my mind should the need arise.

×
×
  • Create New...

Important Information

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