Deep_Blue

My plans to get the recertification by points were thwarted mostly by covid, so after my certification was suspended in March this year, I was left with the decision to take either the CLA-R or the CLA, in a PSI exam center. Luckily I did not read this thread and was fully expecting to nail it due to my 20+ years of actively participating in numerous diverse projects in different companies in different industries. My preparations were IMHO quite okay, took the example exam and a little surprisingly got only 20/30 answers right so would have narrowly failed. 70% means you got to get 21 of them right. Next, I did some very specific reading of the failed topics and designed my first ever XControl as this was gray area for me. Very soon after this, I took my first real test and promptly failed it with the same score of 20/30. More reading and researching, two weeks grace period, and today I passed my CLA-R with 22/30 correct answers ✨. I have to say, most of the comments on this thread about the CLA-R scope are still 100% valid. This test is funny. After finishing answering the questions, I had plenty of time and was able to go through all of the questions the second time. Up until the point I got the results I was confident that I would get a decent score as every question seemed pretty clear. And only 73%, go figure! Safe to say, I'll put more effort on recertification by points after this experience. There's one other thing I'd like to comment, on as it relates to asking outdated questions. The "Merge errors.vi" that was presented in one of the questions has been deprecated in LabVIEW 2010. You shouldn't have to memorize the exact functionality, and it shouldn't appear in the list of questions anymore. I know the functions that have got upgrades, as the earliest LabVIEW version I have been exposed to was 5.1 but that will not be true for everyone taking this test.

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:

Hi LogMAN, thank you for the reply, it does indeed. However attempting to fix the issue with the instructions on that page offered no help for me with this issue. Specifically, even if there at one point were useful information, the links are not working anymore. I created another issue, so if there are any good solutions, the rest of the conversation can be continued here: https://lavag.org/topic/22205-font-issue-in-icon-editor/

Referring to comments in here, I'm looking for a solution to the font issue in the Icon Editor. Selecting different fonts does not seem to change the font in the Icon Editor, specifically in the Icon Text tab input. I've had no luck playing with the Tools=>Options=>Environment=>Linux=>Use pixel-based font sizes, it seems like whatever I select, the font won't change at all. This leads me to believe the issue is with the icon editor and the way it loads the fonts in Linux. I know that it works in Windows, but in Linux it seems as if the Icon Editor always defaults to a same font. It does change, but for the worse if I select any of the builtin(?) fonts, LabVIEW Application / LabVIEW Dialog / LabVIEW System - in the Icon Editor Properties. I've tried most of everything I found from internet plus then some. I've rebuilt the font cache, copied the small fonts .ttf file from windows etc. so I'm thinking the easy fixes are already exhausted. Environment: LabVIEW 2016 on OpenSUSE Leap 42.3. So, looking for help in LAVA forums for this.

This issue arose from the fact that I could not easily figure out a way to fix the glaring font issue in the icon editor, so to go around that I decided to create the letters I use in icons as glyphs instead. These might come in handy for other users as well so I'm sharing them here. Letters.zip There are better solutions for this I'm sure, thus this is only a stop gap hack.

I managed to figure out the solution to this, so will share it here. In this article there was a mention of the setting, that defines where LabVIEW will look for the icons and glyphs. In Options/Paths the default value for the "Default Data Directory" path is /root/natinst/LabVIEW Data. => this then is the correct place for also the user defined glyphs, and I can verify that this works. After any change, do delete the Glyphs.<LVversion>.bin file in the same folder. This will force the LV to recreate the glyph cache, no need to restart LabVEW.

To create user defined glyphs in the icon editor the Windows documentation states the correct place for the .png files is under the \LabVIEW Data\Glyphs\. Using 32-bit LabVIEW 2016 with OpenSuse Leap 42.3 the location should IMHO be ~/natinst/LabVIEW Data/Glyphs but this does not seem to work. I have tested that the glyph files can be loaded from wherever, so the file format is correct, but I would like LabVIEW to load these to the Glyphs menu in Icon editor. Refresh does not help. I'm thinking the glyph files are probably in incorrect folder. Has anyone managed to accomplish this, and could you give me a hand with configuring this?

Hi Neil, google brought me here as I bumped to this feature, and I too expected being able to change the behavior just by updating the source HTML. I do know it is possible, but haven't found the way just yet. Did you find any good solution to what you were doing?

Description of my problem: I have a polymorphic vi. It has two inputs, the first is the polymorphic input that can be one of four types, boolean, path, string or number(double). The other is a typedefined input. I put two instances of this vi to upper level diagram and wire different types of inputs to their polymorphic input. I then wire two instances of a linked typedef constant to the other inputs. When I update the typedef (for example add or remove an entry and apply changes) only one of the polymorhic wirings update while the other is showing broken link. This link is fixed in every polymorphic vi of currently opened upper level vi when I pick another entry of the typedef constant input. If I just open the typedefined list and pick the original entry, the refreshing won't happen. I am in a same situation as I was before finding out how to use the typedefined controls, updating broken links when one change has been made somewhere in the line. :headbang: No picture available at this time, sorry. I hope the description is simple enough. Polymorphic vi's can be created and saved only in professional version. Can you recreate this problem? Any workarounds?

Why not make a cluster of your controls and move the cluster. You can also include the decorations. I currently don't have LabView installed at home, so I can't send an example but if this still bugs you next week, send me email and I'll make and send you an example. :beer:

For me this seems like the transparency after running the vi is actually a redraw-problem. If you move the help window on top of a white window, background will change back from transparent to white again. At least for me it does, is the behaviour the same with other users as well? Furthermore I couldn't download Irene's source code and don't actually know how this is done, thus I'm not able to debug it further. Nice thingy, might use it sometime just for fun if I can reverse the transparency programmatically.

I want to be able to add custom decorations (that are saved as template) from palette to my vi:s. I use this for example when I want to add a certain front panel look (legends, signatures etc.) to vi's I edit. This is how it goes when I use version 6.1 I have edited palettes. Icon at palette points at the template directory. When an icon at palette is changed to type "Merge VI", the front panel decorations appear to my vi even if the diagram view in the template is empty. This is not the case with LV version 7.1 or at least it has changed. If I do have something in diagram view, there is no problem, the decorations come up as they should. I think it is too early to classify this as a bug but this is for sure a change from earlier version functionality.

I have been using library structure to maintain all VIs. Lately I've been reading some comments why keeping them in directories instead would be even better. I'd like to analyze the pros and cons of each approach but I truly know only the library structure. And when I tried to list these, turns out I only have a vague feeling about some of my arguments. Could someone be so kind and help me out by correcting and complementing my list. And finally, which structure is better and why do you think so? Library structure Pros Moving and copying the whole program is easy, just one file ... if you don't count any extra dll- and ini-files. Unused files are automatically removed from library at save time. Upgrading your software to newer LV versions is easy because libraries can hold all the device drivers as well Cons Returning the files to directories can't be done, or at least I don't know how. Referencing a file inside the library might be possible, is it? I think not. If naming is not done correctly, it can be a drag to find a certain file from large library. Directory structure Pros Easy to group logical set of files to different directories With dynamic calls, run time editing is possible Cons Upgrading LV version changes device drivers to new version also. They may but more probably may not work.

I think you caught my point very well and thank you for your answer. As I told in my first post, I needed some data for test sequencer and this data needs to be available whenever I ask for it, immediately. And it also has to be the latest data. This data pops out of com port only every other second and is not available except the user needs this data also and so the UI merrily stores always the latest data. I want to update the UI first and my reasoning was that it was almost acceptable to ask this one data from UI. I still think it almost is but your argument is also too valid :headbang:. I'd rather do this the right way and let the UI do what it is supposed to do. As I'll be thinking of a better way to do this I'd still be more than happy to hear any suggestions as to where I should store this one value. I do want to steer clear of global variables. Should I just add one more thread (=loop) to handle this data? To the next point, Q preview, the preview no doubt is the correct way of approaching this, the reentrancy I (for some long forgotten reason ) tried to achieve only led me to problems. This went straight to top of my task list. And finally the (G)OOP is at the top of my study list. Currently I still lack some insight about it and can't really visualize the way I should build the architecture, but in due time I will. I do hope I'll be ready already at my next project.

Did some reading and found the probable cure for race condition between different readers. Without true understanding I tried to set the receiver to reentrant vi. I should have kept it just the opposite to let the receivers remain in their queue while waiting for commands to receive from the data queue.

Hello everyone, I am building and testing a new (for me) architecture with LV6.1. I made some tests to see if my idea is ready to work but even when the test system worked fine, my more "advanced" (=not so simple) version did not. I'm having a difficult time with probably race condition and perhaps something else as well. I try to outline the system somewhat. There are four threads User interface -send & receive Com port polling -send Test sequencer -send & receive System supervisor -receive (only preview) The user interface is the main communication controller, event handler, sending and receiving messages etc. Second thread is polling communication ports and sending all the information to queue, this information is addressed always to user interface. Test sequencer is time sensitive and it needs to be able to communicate in both directions, ask something from UI and then receive the answer. Sometimes however I do have the luxury to let this thread wait for the answer if I'm sure it is available and won't take long. Long = >100ms. System supervisor would help in debugging and error situations, sort of look over the system and log different things. It's not ready yet. :thumbdown: I use one queue for all communication between different threads. One command is a cluster of receiver's name sender's name timestamp target command string of parameters Senders do not wait for receipts unless the command is ask_value. At first I sent only text through queue but then I changed text to cluster which I now think might contribute to my problems. At some point I receive Error #1 from all my attempts to read the queue even when the read timeout is set to -1. The error message from this doesn't help me much as I don't understand what the problem is but first remedy I'll try is flatten the command cluster to string and send that. As I have more than one receivers I try to address the race condition by letting all receivers (2-3) read (and remove) uncontrolled the first command, check if it is for them and if not, put it back to first place, wait a small random time and try again. If I could somehow lock the queue until the receiver has decided what to do with the command, I could sleep a bit better but for now I think I can do without locking and accept the fact that two readers might swap the first command a couple of times before they receive the one addressed to them. So there. Do I need to lock the queue while I'm reading it? What problems lie ahead if I have to expand my system? Most of all, what improvements would you suggest :question:

This posting is quite old but here goes anyway. First of all the help (ctrl-H) is the best way to address these everyday problems, we all do that extensively, you should consider it too as this is a simple problem. Depending on your application you should consider using named channels. If for some reason this is not an option, you can still control these cards but now your problem seems like you have the device numbers somehow mixed up. Every card gets a device number (you can also change them to your liking at NI-MAX) and you should use this number when you control these cards. Check out attached picture of help window from NI "DIO config.vi" and the control "device". Now look up from NI-MAX the number of each card and debug your program to see whether you are actually controlling the right card.

If your VISA output from RS-232 is of type string as I suppose, your problem is at the converting the read string to decimal value. Pay attention to the representation (U8 in your case) of your indicators and work with the "number to boolean array" to check whether you have the conversion made correctly. If this does not help with your problem, please provide more information. Especially the LV version you are using and perhaps a screenshot of your diagram as well. Attached picture shows some simplified suggestions as to how to go on debugging your problem.