Jump to content

Mads

Members
  • Posts

    400
  • Joined

  • Last visited

  • Days Won

    25

Mads last won the day on November 10

Mads had the most liked content!

2 Followers

About Mads

  • Birthday 12/01/1975

Profile Information

  • Gender
    Male
  • Location
    Bergen, Norway
  • Interests
    Trail running, skiing, fly fishing, science fiction, food and travel.

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    1997

Contact Methods

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Mads's Achievements

Contributor

Contributor (5/14)

  • Conversation Starter Rare
  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare
  • Dedicated Rare

Recent Badges

80

Reputation

  1. You are trying to avoid a soft reboot as well I assume, not just a power cycle..(which would not be necessary anyway). You can issue a killall lvrt command through the ssl interface and it will restart the application, so if you replace the executable then do that you migth suceed (have not tried), here are two related threads: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/quick-software-restart/td-p/3407711 https://forums.ni.com/t5/Real-Time-Measurement-and/Running-a-Real-Time-executable-from-inside-the-CRIO/td-p/3570063
  2. I think that is the point he is trying to make though (based on the title of the thread); that LabVIEW should let us specify which plot we are working on when setting a property without it being overruled by what is done elsewhere as long as that is not actually on the same plot. If e.g. you have one location where you want to set the property of plot 2 and you also have some code in parallel working on a a property of plot 4 they should be able to declare/access the separate plots *without the risk of a race condition*. I agree with @infinitenothing, it is a bad design (I have not checked if anyone has already asked for a change of that in the idea exchange though. It would be a good idea to post there.)
  3. In our commercial software such dialogs and event logs never expose anything in other than an understandable description of what did not go as planned, and if possible a suggestion on what to do to fix it (the code will evaluate events at key locations and produce user friendly interpretations). The only thing included in the dialog that has to do with the underlying code is the error code specified as a sub-code of a more user friendly overall code (which is what they can also see described in the user manual) and source that tells what the software was trying to do. When support gets involved we have other means to dig out the underlying details (task specific event logging, debug-windows etc.).
  4. A related discussion on this is available on the JSONtext Issues page, here: https://bitbucket.org/drjdpowell/jsontext/issues/7/what-should-null-mean-when-extracting-data
  5. One option, perhaps not as flexible as you want but still: OpenG Configuration file VIs can read the ini-file and convert it to clusters, which could then be converted to json using e.g. @drjdpowell's JSONtext... To get up and running with a more flexible solution (i.e. without the need for defined clusters) you could probably pick and merge parts from those two libraries.
  6. I ended up getting too frustrated (again) with the stupidity of having clusters in the GUI involved in key navigation and locked to one terminal . so all controls are individual/primitives in the GUI again. Then the challenge however is that initializing all those individual controls is an inflexible and space-eating affair when done in the traditional graphical way (unbundling extra large clusters). So: How to programmatically fetch all values from a huge cluster and initialize all equivalent individual controls in the GUI? Well, one way I had been using before was to use a Ctrl Val.Set property. That works fine as long as the names of the individual controls in the cluster(s) are unique and match the labels of the controls in the GUI....but you then have to "flatten" the cluster to a list of names and variants. If the cluster(s) do not contain subclusters I use this OpenG-based method: But in this case the cluster is complex - and there are sub-clusters within subclusters, something this code does not handle. The OpenG configuration VIs handle this in "Write INI cluster", but not in a way directly translatable to a list of names and variants as the recursive algorithm to access sub clusters does not translate into this use case.... So I wrote the attached VIs to flatten any complex cluster into its individual element names and variants: The initialization code could alternatively be put into the VI itself instead, and perhaps a blacklist/only init these input could be added, but for now this does the job: It keeps the initialization code very compact and flexible - even though the cluster(s) in question is complex and might change later (sorry, did not rewrite it to JSON instead...not yet at least @drjdpowell😳) Is anyone else doing something similar, perhaps better? Demo of cluster to init of individual controls.zip
  7. I wouldn't want this. User management is difficult to develop, maintain, and keep secure. It would be unwise for NI to roll their own manager; they should integrate existing, tried-and-true technologies. 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?) 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.
  8. 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).
  9. 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?
  10. No complaints, you are doing a fantastic job 😀👍 I edited my examples to include two versions based on JSONtext (attached). PS. I have not tried to scale up the cluster array to see what the differences would be performance-wise yet, they all have their pros and cons usability-wise though. Distributing cluster changes, now with 4 solutions.zip
  11. Aah, thanks, that works.😃 I made a demo of the issue, but you replied just when I was about to post it. The reason I though the $.[0] notation should work was that if I tested it with https://jsonpath.com/ it (almost) seems to find what I wanted... Attached is the demo/test I made...but now with the correct notation for arrays as well. Exploring having Cluster array as JSON.vi
  12. The GUI presents a list of devices by tag in a list box or tree where the user can choose to select one or multiple devices (only of the the same type). If they choose multiple that is one way for me /the code to know whether they want to have changes replicated. If they have selected multiple serial links e.g. the GUI will only show the setup of one link, but changes will be applied to all. There is also a tick box that allows them to put the GUI into "global mode", which is just a shortcut to always apply all changes to all devices of the same type (no need then to select them manually in the listbox/tree). As you say there is one issue with this, and that is if they want to apply a value that is already set for the device chosen by the GUI as the "template". They then have to re-enter the value just to trigger the distribution of it to the other device configurations. This I find OK though - it is part of the "contract"; when you select global mode or multiple devices the user accepts that this will apply *changes* to all - and that is that. With that contract in their head the function makes sense / is intuitive enough. You could add additional GUI elements like an apply all button to sub-sections of the configuration, it depends on how many elements you have in the setup and how often the user would want to replicate them. In my case there are many inputs, but only some of them make sense to replicate; but those often need to be replicated to *many* devices, so the user saves a lot of time having this feature (makes users very happy to have it, so no complaints about such shortcomings... 🙂 ). I do not indicate to the user which values he has changed, that I expect the user to keep track of himself...(he knows what he just did, if he has forgotten already he can always cancel the changes though) but as @hooovahhmentions you could do that... One thing I have not mentioned is that the replication/apply to many/all functionality is kept from touching things that should be unique anyway... Guarding from such changes can be put at different levels, in my case they it is handled by having dedicated event cases for those controls, but in a more generic solution you might want to have a blacklist instead, or include a key in the control name that enabled/disables the replication...
  13. I have not used JSON/JSONtext much, but this sounds like a good plan. If you can bare with me, could you elaborate a bit on how this can be implemented (or point me to an example/documentation that would help)? To use the solution examples I posted as a starting point: Would I replace the array of clusters with a JSON object? In JSONtext, how do I go about replacing the value of multiple items then? If I start with this (instead of the LabVIEW cluster array from the examples): [ {"Enabled":true,"Hello":-2,"Hi":6}, {"Enabled":true,"Hello":-2,"Hi":6}, {"Enabled":true,"Hello":-2,"Hi":6}, {"Enabled":true,"Hello":-2,"Hi":6} ] and try using Set item with the path $.[*].Enabled e.g. when that value changes, it returns an error. Accessing just one of the indexes ($.[0].Enabled e.g.) fails as well. What would be the correct way? Naming each element to be able to use set multiple items with an item names input? (I did successfully rewrite the demo to work with JSON using JSONtext, but then I just treated each array element as a separate JSON string and ran Set item on each of them with the path $.<Label.text>😳) PS. I guess you would also use your SQLite library to store the configuration of each device in a table with the config clusters as JSON strings then...or?🙂
  14. Basic problem: If an element of a given cluster is changed - that value, and that value change alone, should be applied to several other clusters (which will otherwise retain their other element values). Known solutions: In the attached file (LabVIEW 2020 code) I have two ways of doing this: 1) using dynamic events and Set Cluster Elements by Name (OpenG), or 2) by using the Cluster To Array of VData.vi (also from OpenG). (Note: The use of array locals in the examples are there just to simplify the demo). Question: Are there other / better ways of doing it? A bit more background: In configuration windows I sometimes allow users various ways to choose to apply any *changes* globally or to a selection of targets. If e.g. they want to change the baud rate of 3 out of 5 different serial links they can choose the 3 links, and if they change anything in the communication setup of the first of them it will be applied to all 3 links (the rest of their setup will remain as before (they might still have different parity settings e.g.). I usually avoid clusters in the GUI so each change is handled individually, either in a dedicated value change event case (lots of coding needed...), or in a common case that uses the control reference to touch the correct element of the other target's configuration...(less code needed). However, in cases where the number of controls is very high, it can be nice to just have them in a cluster in the GUI as well - and to not have to write event cases to handle the change of each and every cluster element... Distributing cluster changes.zip
  15. Have you installed sudo and added the lvuser to the sudoders list? If you are calling a script make sure lvuser has access to the file (ownership defaults to admin if you have transferred it onto the device logged on as admin). The LabVIEW RT Linux site has some threads with pointers for this, like these: https://forums.ni.com/t5/LabVIEW/Mount-NSF-share-to-NI-Linux/td-p/3822135 https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Is-it-possible-to-close-and-re-open-RTEXE-through-Embedded-UI/td-p/3707540
×
×
  • Create New...

Important Information

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