Jump to content

Deep_Blue

Members
  • Posts

    17
  • Joined

  • Last visited

  • Days Won

    2

Deep_Blue last won the day on September 20

Deep_Blue had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Finland

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since
    2000

Recent Profile Visitors

653 profile views

Deep_Blue's Achievements

Rookie

Rookie (2/14)

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

Recent Badges

5

Reputation

  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:
  2. 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/
  3. 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.
  4. 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.
  5. 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.
  6. 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?
  7. 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?
  8. 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?
  9. 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:
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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:
×
×
  • Create New...

Important Information

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