Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Yesterday
  3. A huge thank you to all who have chimed in here. Here is an update as to where I'm at now. At least one of the USB to RS-232 converter cables work. I have been able to get some communications going with the UPS. I used some software that allowed me to monitor the comm port. While running the Tripp-Lite software I was able to see the protocol the UPS was using. Needless to say it differed in large ways from the document Tripp-Lite supplied me. I was angry at first but I'm over it. In another post I started "My Lack Of Knowledge On Hex" Rolf Kalbermatter sent me to a site https://github.com/networkupstools/nut/blob/master/drivers/tripplitesu.c which has some code (C code) that someone uploaded. Between all the help you guys have given me and the code I think I'm going to be able to get something going. Well See. But honestly thank you guys... You are a huge help... Bob
  4. I think you need to give the User a choice at step 2 of what to do with the loose files. In my case they are just deprecated VIs that never got deleted (deleting files in Current Gen is very inconvenient). Step 3 need a choice too, as adding the shared files to one of the projects will usually be the right choice.
  5. I do use Inno setup, and I am familiar with some of these options. But I've never really tested the cancel functionality and what it might do or how to clean up. Sorry.
  6. I may be incorrect in my assumptions here - but when you converted the single project how did you specify which files to convert in the conversion utility? The logic for creating multiple NXG projects works something like this: If you just selected a lvproj file its easy, we load the project, all files in it, and their dependencies. Then we determine which files will be converted and put them all in the same NXG project. Similarly, if you just select VIs, we load the VIs and their their dependencies, determine which files will be converted, and put them all in the same NXG project. Things get more complicated if you select some combination of VIs and a lvproj, or multiple lvproj files (or a folder with some combination). We load everything and find all dependencies. We create a NXG project for each lvproj file. If there are additional files which are not part of any of the lvproj files we create an additional LooseFiles project for those files. If files are shared between multiple projects, we create a Shared folder next to the projects which contains the shared files. This is because we can't preserve your file disk heirarchy - NXG requires the project and disk hierarchy match, so the only alternative would be to choose one of the projects to be the 'owner' and that didn't seem correct. Unfortunately that leads to these shared files showing up under the 'Links' section of each project. In an ideal case these shared dependencies would be converted into a component in their own project and built into a gll that is shared between the projects, or some similar process. Directly sharing source VIs on disk between projects is not the recommended way of sharing code in NXG. In your case - I have seen this happen in the past where a folder containing a project is converted and some files are not detected to be part of that project so they are put in another project. Autopopulating folders can also make this worse in some cases. In general this is a part of the conversion utility that I would like to simplify because it can be really confusing, it is just not a top priority at the moment.
  7. Something to consider... If the Tripp Lite software Power Alert software is installed on the same host, it may be preventing VISA from reading and writing. If you're trying to monitor the state of your UPS from your application, you could try this https://forums.ni.com/t5/Example-Code/NET-PowerModeChanged-Notifier-Monitor-your-UPS-or-Laptop-Power/ta-p/3493249?profile.language=en
  8. JSONtext was a single project, but for some reason the conversion tool created two projects: "JSONtext" and "LooseFiles_JSONtext for NXG", plus a "Shared" folder, which actually held the JSONtext.gcomp. I fixd the issue by: closing NXG moving the floder with all the JSONtext files into the same "JSONtext" folder as teh JSONtext project reopening the JSONtext project "Excluding" (bad terminology?) the now-broken JSONtext.gcomp "link" (was annoyed there was no way to fix the link by pointing to the new location) "Add file.." to add JSONtext.gcomp from new location (was pleasently surprised that this then fixed all dependencies without LabVIEW CGs endless dialogs)
  9. @rharmon@sandia.gov I'm glad to hear that you're making progress! Hopefully TrippLite is able to help.
  10. Well ~00R means reject. That is of course not to helpful but it tells you that: 1) you can send commands to the device 2) It receives them and reacts to them I checked the source code and it's my bad. The identification command is UID, so try that instead of the IDN. Must have been thinking of GPIB/SCPI when I wrote that part. Now the next command to try is would be the ~00P003VER vor a version query. Then the various status commands STA, STB, STI, STO.
  11. Last week
  12. Everyone... Thank you I contacted the company today honestly tech support is trying to help but they don't understand the communications portion so they can't really help. He offered to ask the subject matter expert if he would be willing to talk to me. That was this morning, still no response so I'm beginning to feel hurt cuz he doesn't want to talk to me... Oh well I guess I'll get over it. Bryan I noticed the typo right away so it didn't effect me, I just followed what you were saying and it helped. Rolf thanks for the explanation, I think it may have really helped. Especially with the NUTS source code. I'm a labview guy so it's not going to be easy but there is a bunch of information in there... I might be able to piece it together. Especially with your explanation. I sent ~00P003IDN and the response was ~00R I kind of expected some model number or something. I think lessons learned here are the protocol document Tripp-Lite is sending out is wrong. The commands I'm sending don't even come close to the format the protocol document states. Again, thanks to everyone who chimed in... I'm feeling optimistic I can get something accomplished here. Bob
  13. Hey all, (Cross-post from ni.com forums) We have a LabVIEW application, which has a LabVIEW-based Installer. This LabVIEW installer is called from within another Inno installer (since our main Inno installer pulls together multiple components, most of them not LabVIEW). Whenever this Inno installer ends, it always asks the user to restart their PC, even if the LabVIEW installer was cancelled. I narrowed it down, and it's reproducible with only the LabVIEW installer, so it's definitely LabVIEW installer's fault. According to Inno's help documentation, "if a program executed in the [Run] section queues files to be replaced on the next reboot (by calling MoveFileEx or by modifying wininit.ini), Setup will detect this and prompt the user to restart the computer at the end of installation." However, as stated above, this dialog is triggered even if the LabVIEW installer was cancelled and wrote no files. Now, the above linked documentation refers to a flag I can put in my installer script to ignore this restart dialog, but it's a global flag, and I would like my other installers to still make use of this handy restart dialog if necessary. Unfortunately it seems LabVIEW installers trigger this even if not actually necessary. Has anyone seen this before? Any ideas how to make my LabVIEW installer NOT muck around with the MoveFileEx or wininit.ini stuff if/when it's not actually needed? Attached is a LabVIEW project and Inno Installer script which easily reproduces the problem. To reproduce: Extract the attached .zip Open test.iss in Inno Setup and click the "Run" button Alternately, just run the built installer under "\Output\test_inno_installer_9.99.0.0.exe" Click Next on 'Select Components' dialog Click Install on 'Ready to Install' dialog When LabVIEW installer pops up click Cancel, then yes (you're sure) See the Restart dialog Thanks! David_L InnoLabVIEWBug.zip
  14. Let me get back to you on this - we are internally discussing some options for improving this - as you noted the activity on the existing beta forum is pretty limited. We want a forum that everyone has access to where we can have collaborative discussions on NXG. The specifics are still being hashed out but I will update when I have more information. Regarding your question about Links - LogMAN's explanation is correct - files under Links are non-addon dependencies located outside your project folder on disk, for example if you use a subVI that is saved elsewhere. This should be uncommon for projects developed from scratch in NXG - it is more common in converted projects - especially if you convert multiple projects with shared dependencies at the same time. It is an aspect of the conversion process that we are looking to improve - at this time I would not recommend converting multiple projects with shared dependencies at the same time - it works but may lead to confusing results.
  15. Welcome to the jungle! New users wouldn't have to convert legacy code, so this is probably not an issue.
  16. I don't know if there is any documentation for this, but a link points to a resource external to your project. You can create your own links by adding files that are not located in your project folder. It looks like your component is located on a shared network location? Maybe the conversion tool uses UNC paths and the project expects mapped paths? Maybe you can re-add those files to get it to work.
  17. So where is a good forum for discussing NXG? Here on LAVA? I'm not one who likes short 1 on 1 private talks nor am I in to "workflows". But I could make lots of feedback on NXG if I have time to craft posts. Right now, for example, I'm trying to make sense of the NXG Project created by the conversion tool from my JSONtext library. I'm completely stuck at not knowing what a "Link" is, and how I can get the JSONtext.gcomp to not be a Link. As a "link", namespaces don't seem to work (I can create a namespace, but not add anything to it) and I suspect this is because a "link" is some kind of leser membership in my project. Maybe. Who knows. I cannot find anything in the NXG help on what a "Link" is, or how to open up the JSONtext.gcomp as not a link. In general, I'm experiencing a lot of "blank stare" moments in trying to figure out this software. Can it really be designed for new users and non-programmers?
  18. Yeah... that was my bad. Sorry about that.
  19. Your UPS seems to be a SmartOnline model. Looking at the NUTS source code I see that the protocol is constructed as follows: ~00<message type><3 bytes: decimal length><3 bytes: command><remainder: parameters> So: 7E 30 30 50 30 30 34 53 4F 4C 31 as crossrulz pointed out translates to ~00P004SOL1 which means - P for Poll - 004 for message length - SOL for relay status - 1 relay number (my guess) The answer is: ~00D0010 which means - D for data - 001 length - 0 relay status Try to send for lolz ~00P003IDN A robust receiver implementatation will first read 4 characters. These should be either ~00D or ~00A. A means an acknowledge of the command without further data and D is a response with additional data. Anything else is an error and you should flush the buffer. So if you receive ~00A you are done, otherwise you read the next three bytes and interpret it as a decimal number. This is the number of remaining bytes to read. As you can see in those sources there are actually several protocols for Tripplite. The other seems to be the Omnivis type protocol which uses :<1 or 2 bytes: command><optional: extra parameters><carriage return> :D\r // request status message even for their USB interfaces that are not HID based.
  20. There might be a typo in @Bryan's example. The first byte should be 7E instead of 7F (based on the previous data). Still, this is guesswork at best and not much better than brute forcing every possible combination. You have proven that your code works, so this is a good time to talk with the supplier. Maybe they can provide you an example or verify that the data you are sending is correct.
  21. Thanks, I cannot believe I did not see the Data Entry Limits as part of the slider properties! For some reason the DigDisps[] property caught my attention and I thought this was the right place to go poking around. This works (as expected!).
  22. I used that FP.NativeWindow property for years and it never failed for me. I was using it on Windows only though. Maybe I could test it on other platforms as well, but I never needed that. Oh, and here's one more way to invoke Heap Peek and Window Monitor (absolutely forgot about it).
  23. There are 2 separate sets of limits: Scale.Maximum/Scale.Minimum and Data Entry Limits.Maximum/Data Entry Limits.Minimum. The digital display simply shows the value stored in the Slide -- in other words, it shows what you'd see from the Slide's terminal, local variable, or Value property node. The underlying issue is that the Slide's value remains unchanged when you update the Scale limits. The Scale limits set the visible range on the GUI but they don't set the range of allowable values. To get the behaviour you want, you don't need to use a property node on the digital display but you must: Set "Respond to value outside limits" to "Coerce" instead of "Ignore" Programmatically update the Data Entry Limits
  24. Thanks Jeff, I have sent the calendly link (but I could not find the bit where we pick the Option 1 or Option 2, sorry! I would like to chat about how I use LabVIEW today).
  25. I am struggling with something I would have assumed is trivial. All I want to do is to be able to programatically set the range of a slider (and also its digital display. I had assumed the digital display would take the same range as the slider but apparently they are separate items.) Anyway, a simple example is shown here and does not work, the Error 1192 comes from the second property node. The first property node correctly sets the slider range. I guess I am being stupid here, can anyone suggest what is wrong with my code? Temperature Slider.vi
  26. Hi everyone, Apologies for the slow response - this thread kicked off a number of internal discussions within NI and I was waiting for some of those discussions to shake out before setting up these engagements. First of all - I have set up a calendly link for scheduling time slots for 1x1 discussions. This is my first time trying calendly, so I have set up 30 minute time slots for three days later this week. Let me know if you have any suggestions or tweaks to make this more effective. Thank you in advance to those of you willing to take the time to talk to me, I appreciate it! In the link I specified two different types of discussions, please specify which kind of discussion you would like to have and I will send you a Microsoft Teams link. The first type is a user interview where we discuss how you use LabVIEW today. This is not focused on NXG, it is a way for me to better understand your workflows and pain points that you encounter today. This helps me better inform design decisions we make in NXG. The second type is a feedback discussion focused on NXG - this is more open format where I will do my best to answer your questions and discuss any feedback you have on NXG. Second - I want to address some of the points in this thread about prior engagements with NI. For the last few years we have been very focused on closing the functionality gaps between LabVIEW and LabVIEW NXG - this means we have not done as much iteration on usability and existing functionality as we would have liked. Big gaps like dynamically loading a VI, sub panels, and hardware support were prioritized higher. As we are getting closer and the gaps are getting smaller, we are re-evaluating some of these longstanding complaints and looking to address them. For example Neil mentioned he had a lengthy discussion a few years ago and didn't see any product changes as a result. I discussed this with the product owner that conducted that discussion, and it (along with several other user interviews that expressed similar concerns) led to several significant design changes - including a major redesign of how we handle tearing tabs out of the editor. In that specific case the redesign represented a significant development effort and was deemed lower priority than closing some of the gaps we mentioned earlier, but as we get through some of those higher priority items I would expect us to look at it again. There were several other areas of feedback which did lead to product changes - such as more color on diagram constants and changes to how the palettes work. We know we need to do better at closing the loop so you can see the impact that these discussions have, and we are working on finding the right venue for having those discussions with the broadest possible audience. Regarding dr powells question about areas which I consider significant improvemented in NXG - there are a few which immediately come to mind 1. The workflow of detecting hardware and getting a first measurement has been significantly improved. We have heard consistent feedback from new users that the getting started experience in LabVIEW is difficult - so called 'blank VI syndrome'. We tried a few different ways of addressing this in LabVIEW, but in NXG automatic detection of hardware is improved and reflected directly in the project and measurement panels let users configure their measurement and basic signal processing before being translated to G code. That is not a workflow that impacts many of the more advanced users on this forum, but it makes LabVIEW more approachable to new users which is important to grow the user base. 2. In my opinion the changes we have made to the project are a huge improvement. Requiring a project, using the project and components to manage the dependencies between files, and mirroring the project file structure on disk (which I realize not everyone is in favor of) has eliminated cross linking. Personally I find it speeds up my development for the editor to be picking the disk location of the files I am creating - especially when I am working with classes and creating a lot of files. 3. Components in general are a big improvement over the options in LabVIEW. They simplify dependency management and encourage modular code architecture. They solve many of the limitations of PPLs. Each component translates to an exe or gll when built, which simplifies build specifications. We have also enforced a strict rule of editor run behavior being the same as built application behavior, which should improve difficult to track down bugs where it works fine in the editor but breaks in a built application. 4. Moving to an xml file format will enable us to eventually have a significantly improved integration with git and other third party tools. We are not there today, but that is where we intend to get to. 5. This is less user-visible, but the underlying architecture of NXG is more flexible than LabVIEW and has been designed for extensions and plugins from the beginning. This is easiest with C#, but it means that community members who know C# are able to extend NXG in a myriad of ways that are not possible with LabVIEW. As I said in my previous post - LabVIEW NXG is still a work in-progress. It is not ready for complex projects yet, but we are getting closer and moving quickly. Similar to what Stephen said - I believe the vector is good, and community engagement helps us refine our direction. Please grab a slot for a 1x1 discussion if you want to discuss this further or are willing to talk with me about your current workflows. Thanks!
  1. Load more activity
  • Create New...

Important Information

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