Jump to content

hooovahh

Moderators
  • Posts

    3,169
  • Joined

  • Last visited

  • Days Won

    229

hooovahh last won the day on January 17

hooovahh had the most liked content!

11 Followers

About hooovahh

Profile Information

  • Gender
    Male
  • Location
    Detroit MI

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    2004

Recent Profile Visitors

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

hooovahh's Achievements

  1. Yes I do have some issues with flattening a cluster to a string for logging. I already have a set of code in this package for reading and writing cluster data to a TDMS file. It just doesn't support the various TDMS Classes I made, it works on the TDMS reference alone. But the code in this package has a ton of overhead. It flattens the string to a string, with human readable decimals, and tab delimiters. I posted an update on the dark side here which works much better but by writing the array of bytes as a string, with padding used on the bytes that need escape characters. It also supports different methods of compression. (some of this is in the VIPM.IO package too) This works much better but I found a bug in regards to how the extended ASCII table is used. If you write a cluster to a TDMS file, then FTP that file over to a Linux RT target, it won't be able to read the bytes where the 8th bit is used. I believe this to be a bug that NI hasn't confirmed. In any case extra escaping characters can be used for these cases too. Anyway this is all just to say that at the moment the reading and writing of cluster data needs some attention before being updated in this package.
  2. Oh that is better than renaming EXEs and copying them. A native solution from NI would be even better but I'm guessing they don't get this kind of request often. Still if the embedded target has some desktop like functionality it isn't crazy to be able to run arbitrary LabVIEW binaries.
  3. So combining the script to stop and start the NI service, with a couple of file copies or moves, you could get something that works but is pretty clunky. When the user tries to switch programs, it will need to copy over the other rtexe, replacing the current one, then have it call a script to stop and start the NI service. That might bring up the new rtexe, but will have issues if you restart the controller as it will run the now new rtexe instead of the older one. It might be possible to on start up, copy over the first rtexe back before the NI service starts. All very clunky, and probably not what you want but possible. Other developers would probably suggest trying to just make a single LabVIEW project that combines the code from both into a single application.
  4. I'll take it! Also a Texas Tea is like a long island tea but with tequila instead of gin. I like gin, and don't usually like tequila but man when I'm at NI week, those are amazing. Thank you @Mark Balla.
  5. Okay here is a quick first update to the Write VIM that has special code if you are writing an analog waveform, or an array of analog waveforms. It will write the waveform properties and then flush the file, then write the 1D array of doubles for a scalar, or a 2D array for a 1D array of waveforms. On the next write it will see the property for the waveform exists, and not write it again, but the dT between the write must match. If it doesn't it generates an error. This is still using just the normal TDMS write. So if you are having memory issues, this doesn't use the advanced stuff, and might not fix it. Partially because don't have experience with advanced TDMS stuff, and also because I don't fully understand the original issue. Write Tremendous TDMS - Waveform.vimSet Waveform Properties.vi Also I noticed that there is a disabled structure that has a partially implemented cluster write. I should probably finish and test that.
  6. Never meet your heroes. Unless it's me and you're planning on buying me a Texas Tea at the piano bar. In that case you should definitely meet your heroes.
  7. So I'm still reading the thread, but I don't fully understand the issue, or the solution. I get that you are saying there is some issue with the normal TDMS Write, and this issue is most commonly seen when writing waveform data. And I get that waveform data really is just a 1D array of doubles, with a bunch of special properties. So I can absolutely update the write function to instead of writing a waveform, write the properties and the doubles differently. But I don't have much experience with the advanced primitives, and I'm not sure how they come into play. Is it possible to attach a VI that demonstrates this uncontrollable memory leaking/growing problem?
  8. I get what you are saying, and agree with some of your comparisons. I've seen on the forums a few times when an inexperience LabVIEW developer is like "I know nothing about programming but was able to make a spectrum analyzer using Express VIs." And half the replies will be from people like me saying "You're doing it wrong" and they will replay with "Well yeah maybe, but it sure got the job done without much work." That's sorta how I feel here. Your criticism of Network Steams are valid. And better solutions can be made. I'm just glad that I was able to make a synchronous network transport mechanism that uses VIMs, has status, automatic reconnection, and can target applications running on different platforms and different operating systems. All of this with no networking experience, and the amount of effort needed to make this was pretty minimal. I forgot to update this thread, but I did present this to the user group here, and uploaded the package to VIPM.IO here.
  9. Around there, if I had to guess I'd say 8.0 or 8.20.
  10. Okay I may have a solution, but I don't know if it will work in your use case or not. If you wire a cluster to an Add, it will work if all elements in the cluster support the Add function individually. So you could have a VIM that has a Type Specialized structure, and perform a type cast if all elements in the cluster support the Add. Oddly enough in my test I used a Timestamp Constant, and that makes a pink wire, but supports the Add, and is a fixed size. But I'm not sure I understand what you want done into the byte array. If you are just trying to get a byte representation of a cluster, and you want to use a fixed string for those cluster elements, it probably would just be best to iterate over element in the cluster with while loop recursion. What I think you what can still be done with a VIM, using the Type Cast in one type specialized case, and then if that fails, then to iterate over all elements.
  11. Thanks I appreciate the feedback and I'll change it, but not push out a new version of the package for a change like this. Also your comment does at least help me know that someone does use it on a cRIO and finds it useful. Edit: Actually looking at the newest version of the package here, and the newest version of the package on VIPM.IO, the front panel looks like this. And actually I think I always put defaults in parenthesis and not brackets, and I don't think I would bold a front panel label. Are you sure someone didn't edit that?
  12. I mean it is a programming technique for making code more portable, by including small external dependencies. But I agree that having embedded programs AND having Run When Open is concerning. I mean other than the Abort All VIs from AQ, I can't think of a good reason a file downloaded would be set to run when opened. I did see in a controlled environment, Run When Opened was being used in place of making an EXE. Operators would just double click the Main.vi shortcut, it would open it in LabVIEW because they had the full IDE, and then it would run. It wasn't a good practice to have and I advised against it. But those are the only two cases I can think of where it could be used. Edit: I do remember embedding a VI as a block diagram constant too. In my LabVIEW Tray Launcher there is an Abort All VIs, which needs to be saved in the oldest version of LabVIEW supported. If the VI was a static reference the application builder would resave it, but then I couldn't do an Open VI Reference on other versions of LabVIEW. So I saved it as a constant, then when needed it would get saved to a temp location and ran. But again this wasn't a Run When Open situation.
  13. This looks similar to the issue I mentioned earlier with SSE instructions. The guess at the time was that the translation layer of Windows for ARM for running x86 applications, didn't fully support all the instructions. This is why in my experimentation with LabVIEW on Windows 10 on a Pi, I had to go with LabVIEW 2016. With 2016 there is settings in the application builder that can turn SSE optimizations off. Since VIPM is built using LabVIEW using those SSE instructions, it can't run. MAX corrupting Windows is a new one.
  14. I'm not sure how to change this either, I'll contact the site admin.
  15. I agree that people have been asking for unicode support in LabVIEW for a while. But there's a good chance NXG development definitely started more than 10 years ago. The first alpha available for people outside of NI was around 2013. And the Web UI Builder was showcased at NI Week 2010, which has some core components of what NXG would become.
×
×
  • Create New...

Important Information

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