Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 09/18/2021 in Posts

  1. So I managed to find the underlying issue and at least one solution to it - sharing the information here. The Icon editor enumerates the font list in linux with command 'fc-list'. With OpenSUSE 43.2 / LV 2016 combo the fontlist looks like this: The listed fonts are essentially a list of the font files with full paths, and that does not work well with the font tool LV uses. If this list looks similar to yours and the fonts are not looking pretty, I have a solution for you - read on. To fix this a command 'fc-list : family' should be used instead, to come up with a list like this: There are two solutions (and I'm sure there are more) - you can decide which one to pursue depending on your expertise. As the Icon Editor in LV2016 (starting with LV2011 I think) is in packed library for execution optimizing purposes, the Icon Editor code can't directly be altered to fix this. One can come up with a solution where the command 'fc-list' is overridden in linux so it will always use the (proper for LabVIEW) format 'fc-list : family'. This may have some unwanted side effects if other programs use the command in similar fashion, so this may not be the best solution. It would be pretty easy to use for assessing whether this could be your problem also. There are multiple trivial ways of implementing this, so I won't be giving an exact solution - here is a list of them: https://lmgtfy.app/?q=override+command+in+linux Darren Nattinger has provided the source code for Enhanced Icon editor in https://forums.ni.com/t5/Enhanced-Icon-Editor/Icon-Editor-Source-Files-for-LabVIEW-2016/m-p/3538808 - You can replace the packed library LabVIEW uses as editor with this source. There are easy 3 step instructions on the site - even I managed to do that. Please give kudos to Darren should you go this way. When you have the shipped Icon Editor replaced with the source, you can directly edit the file in /usr/local/natinst/LabVIEW-2016/resource/plugins/NIIconEditor/Miscellaneous/Font/Linux.vi so it uses the correct form, like this:
    5 points
  2. Since Latin for six is "sex", we could have gone for "sexidecimal".
    4 points
  3. Shameless plug but feedback would be great since there's a lot that's changed. A few more eyes on it would help immensely before going live. The Encryption Compendium for LabVIEW (ECL) has had a major update. It's completed and a couple of weeks away from release as the documentation is in progress so there may be a few errors on that front. It's a commercial package so the gibs free crowd will, I hope, be disappointed. So what's new? IPv6 support (Thanks Rolf for your help with that). I've been wanting this for sooooo long but it required moving away from the NI primitives and nasty text programming. I bit the bullet and now have it, although a lot less hair SFTP Since NI released their poultry offering I thought I'd productionise the SFTP I had in my back pocket for quite a while and offer something actually useful. It comes with a full client example and supports recursive uploads, downloads and deletions (be careful with that last one). It also uses events for progress and status feedback in a similar fashion to the Websockets below. The event topology will be come a common feature of protocols in future additions. Websockets The ECL is a better home than a separate product since it was very difficult to distribute when trying to support TLS. Reworked from the ground, up it sits nicely in ECL and is the start of more encrypted protocol support in the future. Oh yes. Almost forgot. The ability to use Windows Certificate Store because ... why not? (and I wish I had thought of it ) If anyone would like to play before its release proper in a couple of weeks time, I can give you a trial copy (valid for 30 days). PM me and I'll send you a link.
    3 points
  4. I can say without any doubt that online clothing stuff is good quality or not.
    3 points
  5. I like resizable UIs, and that often means custom code to handle some of the operations in the UI. One such feature I like is a vertical array, that shows more rows, as the window size gets larger and can show more. I've used code like this a few times and figured the community might like it too. When doing this there are times when I want a user to be able to add more rows, and some times that it needs to either be static, or set by some other outside variable. So in this demo is also a way to link a vertical scrollbar that is a separate control, and have it move, and get set, so that it looks like it is linked to the array control. But this will coerce, and not allow more rows to be seen, than the number of elements in the array. At the moment this only supports 1D arrays, and only in the vertical direction. Code is saved in 2020. Array Resize and Scrollbar Link.zip
    3 points
  6. I am actual about to commit to making the next release in LaVIEW 2019, rather than 2017, as VIMs were very new in 2017 and both buggy and of limited capability.
    2 points
  7. Today I Learned... you can convert from upper case to lower case like this! Clever design hidden in plain sight. See for yourself
    2 points
  8. At one point I heard NXG called "Better LabVIEW" and someone else suggested the real name was "Beta LabVIEW". I've also heard of it called to as LabVIEW 20xx, or Current Gen (CG). I like Lab-deja-VIEW.
    2 points
  9. I just have to add this fun vim using your (@drjdpowell) SQLite library. It's LINQ for LabVIEW (I only spent 20 minutes on it so it's a bit rough) LcArray_LINQ.vim
    2 points
  10. Thank you for posting this. It's very helpful and informative. I was noticing icon font issues in LabVIEW 2020 Community Edition for Linux, so it doesn't look like NI has fixed (or knew about) the issue in LV 2020 for Linux either.
    2 points
  11. The current pink wire datatype needs to remain as a "byte string" plus "locally encoded text string" to maintain backwards compatibility. A new type of wire (Purple? Darker than pink, paler than DAQmx wires?) should be introduced as a "universal text string" datatype. Explicit conversion (with user-selectable encoding) should be done to change pink wires to purple wires and vice-versa. Binary nodes like "TCP Read"/"TCP Write" should only use pink wires. Purple wires not accepted. Text nodes like "Read from Text File"/"Write to Text File" should ideally only use purple wires, but they need to allow pink wires too for backwards compatibility. VI Analyzer should flag the use of pink wires with these nodes. Perhaps a project-wide setting could be introduced to disable the use of pink wires for text nodes.
    1 point
  12. The lvanlys will return an error code if there is a NaN in the array, this extra feature probably explains a part of the difference in exec time.
    1 point
  13. Not natively in LabVIEW. You have to use the IShellwindows interface in windows 10.
    1 point
  14. You didn't look very hard; did you! We've just been discussing the callback functions and posted examples of using them. The answer to your question though is no. you cannot use them in the way you are thinking.
    1 point
  15. In the Window menu on the LabVIEW toolbar there is an "All Windows" [last] choice (CTRL+SHIFT+W) that pops up a dialogue which you can sort. There is also a VI hierarchy and Class hierarchy graphical representation of VI's that are in memory that are accessible from the "View" menu in the toolbar. That may be easier for you if you are familiar with the hierarchies and the project is not too large (also highlights the importance of VI icons).
    1 point
  16. You could implement it using the LabVIEW memory manager but it's not for the faint-at-heart. I once played with it for a circular buffer which isn't a million miles away from what you need. Oooh. Look. Words similar
    1 point
  17. Synology is great, I love it for my home NAS. But.... I have a strong suspicion we are all having a sensible conversation in response to a spam original post. 😂
    1 point
  18. Indeed. It's all working great now. Thanks all for the help. When I get 5 mins I'll put together a working demo project and post it here.
    1 point
  19. Your problem is that the correct definition for those functions in terms of basic datatypes would be: MgErr (*FunctionName)(void* *data); This is a reference to a pointer, which makes all of the difference. A little more clearly written as: MgErr (*FunctionName)(void **data);
    1 point
  20. My experience with Raspberry PI is they take a lot of work to get to do what you want. And then it isn't that great. For NAS I use these https://shop.westerndigital.com/products/network-attached-storage/wd-my-cloud-expert-series-ex2-ultra#WDBVBZ0000NCH-NESN Easy to use and good quality. My time is worth more than dinking with a PI....
    1 point
  21. I don't quite have a working example but the logic for allocation and deallocation is pretty much as explained by JKSH already. But that is not where it would be very useful really. What he does is simply calculating the time difference between when the VI hierarchy containing the CLFN was started until it was terminated. Not that useful really. 😀 The usefulness is in the third function AbortCallback() and the actual CLFN function itself. // Our data structure to manage the asynchronous management typedef struct { time_t time; int state; LStrHandle buff; } MyManagedStruct; // These are the CLFN Callback functions. You could either have multiple sets of Callback functions each operating on their own data // structure as InstanceDataPtr for one or more functions or one set for an entire library. Using the same data structure for all. In // the latter case these functions will need to be a bit smarter to determine differences for different functions or function sets // based on extra info in the data structure but it is a lot easier to manage, since you don't have different Callback functions for // different CLFNs. MgErr LibXYZReserve(InstanceDataPtr *data) { // LabVIEW wants us to initialize our instance data pointer. If everything fits into a pointer // we could just use it, otherwise we allocate a memory buffer and assign its pointer to // the instanceDataPtr MyManagedStruct *myData; if (!*data) { // We got a NULL pointer, allocate our struct. This should be the standard unless the VI was run before and we forgot to // assign the Unreserve function or didn't deallocate or clear the InstanceDataPtr in there. *data = (InstanceDataPtr)malloc(sizeof(MyManagedStruct)); if (!*data) return mFullErr; memset(*data, 0, sizeof(MyManagedStruct)); } myData = (MyManagedStruct*)*data; myData->time = time(NULL); myData->state = Idle; return noErr; } MgErr LibXYZUnreserve(InstanceDataPtr *data) { // LabVIEW wants us to deallocate a instance data pointer if (*data) { MyManagedStruct *myData = (MyManagedStruct*)*data; // We could check if there is still something active and signal to abort and wait for it // to have aborted but it's better to do that in the Abort callback ....... // Deallocate all resources if (myData->buff) DSDisposeHandle(myData->buff); // Deallocate our memory buffer and assign NULL to the InstanceDataPointer free(*data) *data = NULL; } return noErr; } MgErr LibXYZAbort(InstanceDataPtr *data) { // LabVIEW wants us to abort a pending operation if (*data) { MyManagedStruct *myData = (MyManagedStruct*)*data; // In a real application we do probably want to first check that there is actually something to abort and // if so signal an abort and then wait for the function to actually have aborted. // This here is very simple and not fully thread safe. Better would be to use an Event or Notifier // or whatever or at least use atomic memory access functions with semaphores or similar. myData->state = Abort; } return noErr; } // This is the actual function that is called by the Call Library Node MgErr LibXYZBlockingFunc1(........, InstanceDataPtr *data) { if (*data) { MyManagedStruct *myData = (MyManagedStruct*)*data; myData->state = Running; // keep looping until abort is set to true while (myData->state != Abort) { if (LongOperationFinished(myData)) break; } myData->state = Idle; } else { // Shouldn't happen but maybe we can operate synchronous and risk locking the // machine when the user tries to abort us. } return noErr; } When you now configure a CLFN, you can assign an extra parameter as InstanceDataPtr. This terminal will be greyed out as you can not connect anything to it on the diagram. But LabVIEW will pass it the InstanceDataPtr that you have created in the ReserveCallback() function configuration for that CLFN. And each CLFN on a diagram has its own InstanceDataPtr that is only valid for that specific CLFN. And if your VI is set reentrant LabVIEW will maintain an InstanceDataPtr per CLFN per reentrant instance!
    1 point
  22. @Rolf Kalbermatter has the answer, as usual: The parameter type is a pointer-to-InstanceDataPtr (i.e. a pointer-to-a-pointer, or a Handle in LabVIEW terms). LabVIEW owns the handle, you own the data pointer: You allocate the data in Reserve and you can access that same data in Unreserve/Abort. LabVIEW can't free your pointer since it doesn't know the type/size of your data. // C++ example #include <ctime> MgErr reserveCallback(InstanceDataPtr* instanceState) { if (*instanceState == nullptr) { time_t* start = new time_t; *start = time(nullptr); *instanceState = start; } else { // We should never reach this point, unless the InstanceDataPtr was not cleared after the last run } return 0; } MgErr unreserveCallback(InstanceDataPtr* instanceState) { time_t end = time(nullptr); time_t* start = static_cast<time_t*>(*instanceState); // Calculate how much time has passed between reserving and unreserving double elapsedSecs = difftime(end, *start); // Note: The handle must be explicitly cleared, otherwise the LabVIEW IDE will pass the old pointer // to reserveCallback() when the VI is re-run delete start; *instanceState = nullptr; return 0; }
    1 point
  23. You could use openmediavault with your Pi. Works fine with a PI4 4GB with externally powered USB-C drives or a powered USB-C hub. Or use a SATA hat to connect SATA drives. https://www.openmediavault.org/ VDB
    1 point
  24. You are aware that the storage of a Raspberry Pi is actually an SD Flash card? These have a fairly limited lifetime if written to often. So I don't think a Raspberry Pi would be a great platform for a NAS. Maybe if you use a Raspberry Pi Compute Module. You can get them with onboard eMMC Flash memory which is more reliable than an SD card. Still it is soldered on the board and when the flash memory eventually dies (all flash memory eventually dies if you write often to it) then the whole module is bad.
    1 point
  25. Well this all depends on what you have, what your budget is, and what purpose the NAS serves. I have lots of random half working computers, so for me making a NAS was about reusing what I could, and upgrading what. I also use mine for a Plex server, and for that I wanted hardware accelerated transcoding, which means an external GPU. So for me a Pi wouldn't work very well at all. But if you are more concerned with power consumption, and formfactor then a Pi might be a good option. For that there's lots of tutorials and configurations, with the easiest just being a USB hard drive connected.
    1 point
  26. This is how I include the RTE as part of an installer. Note: outside of the scope of the installer I manually unpack the relevant NI distributed RTE
    1 point
  27. I would definitely not use a Swap Values here as it just makes the code confusing. Of the three I think the top is the most natural (but there is something about the inner dequeue which does not sit well with me).
    1 point
  28. I just include the whole runtime and don't bother trying to cherry pick the perfect dependencies. I did try this once upon a time but could never figure out the right dependencies.
    1 point
  29. Is it ever conceivable that there will be more than two Queues to monitor? If so then the last one would scale up better. That being said it isn't the one I'd find myself using, just because the other two are much more readable. I'd probably go with the first one. Swap values is pretty handy when you actually need to swap two values. Here you aren't really using one of the values. From a memory or speed perspective I bet you can't measure the small amount of difference (if any) that is taking place.
    1 point
  30. You will have to setup the triggering, similar to the snippet below. I don't have those DAQs, so I can't test it. Edit: You might have to do SW trigger, Each DAQ will have its own trigger source (PFI0), and the software will generate a transition on both lines.
    1 point
  31. Another option... Use a third party installer. InnoSetup works really well.
    1 point
  32. Of course there is something they could do. I expect the use of the ANSI versions of the file operations is making them resistant. I've my own set of compane equivalent of the native file operations that do it just fine - it's the Path Control that is the problem.
    1 point
  33. There are many links on the Internet to tell you how to configure git to use custom tools for VI. Many are wrong. Yesterday, I and another developer outside NI worked through the sequence and got it working repeatably on both of our machines. Here is the process. Save both of the attached files someplace permanent on your hard drive that is outside of any particular git repo. We used C:\Users\<<username>>\AppData\Local\Programs\GIT\bin _LVCompareWrapper.sh_LVMergeWrapper.sh Modify your global git config file. It is saved at C:\Users\<<username>>\.gitconfig You need to add the following lines: [mergetool "sourcetree"] cmd = 'C:/Users/smercer/AppData/Local/Programs/GIT/bin/_LVMergeWrapper.sh' \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\" trustExitCode = true [difftool "sourcetree"] cmd = 'C:/Users/smercer/AppData/Local/Programs/GIT/bin/_LVCompareWrapper.sh' \"$REMOTE\" \"$LOCAL\" [merge] tool = sourcetree [diff] tool = sourcetree That's it. There are lots of ways to edit the .gitconfig from the command line or by using SourceTree's UI... if you know those ways, go ahead and use them.
    1 point
  34. If you are a student, I'm pretty sure there are boring tasks that can be automated. Something that's special so you are not likely to find existing tools. But since you are a student, simply reinventing something, cloning a board game you like (I make minesweeper in pretty much any programming languages I work with), remaking msPaint is not a "stupid" decision as it would be as a pro. For example for work, I did a picture manager program. Pictures can drag+drop sorted, comments can be assigned, picture entries can be colored (for marking purposes), images can be cropped with arbitrary angled rectangles. And all pictures can be inserted into a Word document using the report generation toolkit and some VB scripting. This is just a small tool but it can be extended infinitely and has lot of areas that you can practice. And doesn't need any hardware (measurement or controller devices). Just a computer. EDIT: in general, Labview is a pretty productive language for GUI heavy applications. Graphs are very typical Labview things and they can be customized beyond a mere measurement plotting widget. So for a student project I would prefer something that involves graphs in some ways, usual or unusual ways (like some task scheduler or fancy calendar-thing, just throwing ideas). Another idea is making some cellular automata, like Conway's game of life. You could and controls to it, maybe even drawing the initial filled cells (you have to solve the rendering of the field: table?/graph?/picture? and you have to handle mouse clicks) and add some additional graphs that plot some interesting data vs. time diagrams. Like the percentage of alive cells, or whatever. Maybe you could also make some overlay heat map on the field to see if there are places that alive cells are more common. You could add a menu to switch between different automatas. Maybe adding an option of hexagonal field. Man, now I want to make it 😣
    1 point
  35. Here is one that involves a nice mix of small challenges: My first assignment after being hired as an engineer back in 1998 was to write a multiplexer and demultiplexer. In that case we had 8 instruments outputting readings as an ASCII string every second (fixed length message containing a numeric value: "AA 2500BB\r\n"), and all those strings had to be read from 8 separate serial ports, tagged with a channel (c1, c2, c3 etc..) and then sent on through a single serial link (because we physically only had two wires available) to another PC where the signals would be split into the original 8 live values...Unless you are already familiar with serial IO you might want to simulate the physical parts at first to finish the downstream logic, then you can add the physical / serial communication bits at the end (in case you end up spending too much time on that to finish everything).
    1 point
  36. How about something with the File IO? Maybe copy all files and folders from one location to another and list the files that were new or overwritten? Maybe open a text file with times and values in it then graph it? Maybe import a text file into a table and color the values that are greater than some value red, and lower than some value green?
    1 point
  37. I was just recently sorely wishing NI-IMAQ had by-value image frames. — James PS to manigreatus> have you considered turning it inside out; make a by-value object and keep it in a DVR if (and only if) your application needs it?
    1 point
×
×
  • Create New...

Important Information

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