Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Zyl last won the day on November 16 2010

Zyl had the most liked content!

About Zyl

  • Birthday 12/07/1984

Profile Information

  • Gender
  • Location
    Montreal, Canada

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since

Zyl's Achievements


Newbie (1/14)

  • Dedicated Rare
  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges



  1. Hi Francois, I was seeing the DVR more like a 'pointer' (the address in memory) on the class, not a representation of the class itself. To me, if it is really a pointer, and the variable containing the pointer is public, I should be able to access the pointer everywhere. But of course, I wouldn't be able to use what's pointed (because it is private). This is the way I was seing this, I am maybe far away from the truth 🙂 Anyway, I wonder if it is the same behavior in C++ (or other OO language using pointers).... For the 'interface' part of the problem, yes the lvclass is a lib. But I guess that originally, the code was designed to allow building a PPL. So I guess that's why the interface is in a LVLIB and it contains the lvclass.
  2. Hi! The class itself is private (set a s private in the lvlib), so nobody with the DVR can use what's in the class outside the functions in the LVLIB. The control containing the reference is public. IMO, I should be able to create the control outside the lvlib.
  3. Hi everybody, I'm running into something I don't really understand. Maybe you can help me here ! I've got a LVLIB that is used as an 'Interface': it exposes public VIs which wrap around public functions of a private class (see code attached) . The class is private because I want to force the users to use the 'interface' functions. In one of my interface VI, I create a DVR on the private class (Interface_init). The DVR is stored into a typedef (FClass_DVR.ctl) and this typedef is the 'reference' that link all the interface public functions. In TestCode.vi (which is not part of the lvlib and illustrates the standard code that a user can create to use my driver), I can call my public interface functions and link them without any problem. But as soon as I create an indicator on that reference (to create a state-machine-context-cluster for example), my TestCode VI breaks ! The error returned is : This VI cannot use the LabVIEW class control because of library access scope. The LabVIEW class is a private library item and can only be accessed from inside the same library or libraries contained in that library. I understand that the class is private. But the DVR is contained into a public control. Using an In Place structure on that DVR into TestCode would not work, since the class is private. So why is the DVR control problematic at that point ? Creating it do not breaks any access protection... Am I missing something ? DVR Private POC.zip
  4. Hi ! I'm developping a TestStand UI in LabVIEW. Within this UI, I want to display the front panel of VIs that are played in a TS sequence into a subpanel. It works fine ... except for values that were set into the 'sequence' VI (LV Step) before the front panel was loaded into the UI subpanel. If I want to 'redraw' them I have to read a property on the front panel controls into my LV step... I want my code to be as more generic as a possible, so I dont' want to add extra code into my LV step just to ensure that it will be displayed correctly into the subpanel. Do you have any idea how to force a front panel to redraw ENTIRELY (or at least all control/indicators visible) ? Note : I must be able to do it through VI server fron the 'outside' of the VI.
  5. We do commit broken code ! And we think it is important : the trunk is the 'ongoing' state of the developement. So it is normal that the code is broken if prototype or wrong code is delivered. If we cannot build and make tests with the code, there is no chance that a stable release will be tagged. For the rest it only relies on team management and communication. But at least wit heth locking system and identified commit, we have a chance to know what is going on or at least who did it.
  6. Thank you for your advices! I'll go with Mercurial and my Synology !
  7. Hi! Thank you for all these answers. Hooovah: Thank you for the precision on separating compiled code / source. however for some of our customers, we still use old LV versions (2010..2013). So I guess the issues can still be a problem for these projects. Smithd : Locking on SVN helps a lot when working on big projects (I had once more than 10 developpers working on the same project) and it prevents headackes due to the merging process in LV. Since a locked file is read-only, and with LV well set, you don't get 'modified' VIs just because you opened them. Our rule is to unlock one by one the files to modify and to commit right after any modification is made, so that it unlocks the file rapidly. Locking issues with developpers is really rare. Neil : I plan to host the server on our Synology NAS, so everything stays 'in house'. For some of our customers it is (still) comforting to 'know' that the sources are not in the cloud. But I plan to use TortoiseHg as our client. Do you have any specific settings that you apply to your client ? To LV because you use Mercurial ? Antoine: I've seen that too on Twitter. And it let me think that Mercurial would be a better choice than Git (mainly for the non-mergeable files and Trunk-base dev rate). But so many people rely on Git (even NI lately) instead of Mercurial. So I was thinking that there is a particular reason about it.
  8. Hi ! I know that there are numerous threads about SCC, but none really helped me to answer clearly this question : I want to move from SVN to a DSCC to be able to commit even if I cannot connect to my server, which DSCC should I use between Git and Mercurial AND how should I set it ? I use SVN for years now, and I always apply the same rules to be able to work with several developpers on the same projects : Files are all locked, a developper MUST unlock them to work on them Locked files are read-only LabVIEW is set to treat read-only files as locked and not to save automatic changes (old habit to avoid LV to recompile and ask to a VI for non-functionnal 'modifications') These settings work perfectly fine for us. Can I replicate such settings with Git / Mercurial ? Is there a point to do it ? I have a video from Fabiola explaining how she uses Mercurial with LV. One of her LV setting is to separate compile code from source code (I guess to avoid unnecessary changes made by the compiler when opening a VI for example to be taken into account by the DSCC). I've heard that this setting is sometimes buggy and generate more problems than really helping. Is it still true with new LV versions ? Reading some comparisons between Git and Mercurial, I would tend to use Mercurial (seems easier to use, more particularly by SVN users). But Git seems to be more popular even in the LV community. Is there any specific reason (related to LV or not) to that ? Thank you for your help and opinions ! Cyril
  9. Hi! Maybe you can take a look to the advanced plotting API : http://advancedplotting.github.io/
  10. This idea is mine and I posted back in 2014... Since then it is maked as 'In dev'.... In 2014 I was mainly developping my own RT apps, with my own framework (that is why I built a web console based on WebSocket). But now I mainly work with VeriStand. Even if my console is still usefull, it is even less easy to use it with VS. Looking at the number of Kudos on thsi idea I tought that NI would have put more eforts into it, it such a basic option...
  11. The 'console' is there on VxWorks and PharLaps system since ... a long time (I would say since the first release of LV RT, but I'm not 100% sure). You can see it indeed with video-hardware equipped targets but also on the configuration web page. So the video hardware is not necessary. Publishing string is done calling 'RT Debug String' VI. Works fine on VxWorks and PharLap cRIOs, and has absolutely no effect on Linux RT cRIOs (no error, no effect, seems to be no op when 'Write to monitor' is selected). When you are migrating code from 1 platform to another, you expect keeping the same behaviour (tracing access in this case).
  12. I perfectly understand that there are many options to trace that comes with Linux. But I don't think that NI not picking one solution is a good idea. When you use for years the RT targets and get use to use the console to debug, when you switch to Linux RT you've got nothing anymore... or at least nothing immediately operational... All previous code routing messages to the console work without error, but actually do nothing, and you keep searching for the 'console'. When you do that in conjonction with 'linux' keyword, you just fall onto posts saying that the console is now on ... the serial port ! So I agree with you that Linux RT provides a lot of possibilities but most of the people using RT targets are not Unix-fan-professionnals... A clear position from NI saying that 'RT console' VIs should be changed to 'Syslog' VIs or even better, directly provide the syslog functionnality onto Linux RT targets when you use this VI would have been clever... (my 2 cents...)
  13. Hi Rolf, I definitely should look deeper at Syslog. I don't like the 'file' option because it doesn't tell me 'immediately' what is going on in the target. And most of the targets I have are equipped with a tiny HDD (mostly 9063) so the file size monitoring would be 'critical'. I'm pretty sure it can work with VeriStand, but I must ensure that this solution can work on other supported targets (I've got PharLap and Windows targets as well). And again, I've got to design a specific (but reusable) monitoring thread in each custom device that may be played on the targets. Compared to the console (very simple and enough for fast debug) that was native on the other targets, IMO the lack of this tool on Linux RT targets complicates things. Do you have a syslog viewer app to recommend ? Also a specific syslog LV lib that can be used ? Thanks !
  14. Syslog is good point! I'll try that in future devs. But I guess that it will again a 'pain' to have this working with VeriStand...
  15. Thank you for your answer. Yes indeed, the debug is difficult in the case you're using VeriStand : you have no way to get the RT VI FP when it runs on the target. File is an idea but you can only read it when th execution is done, not 'live'. In MAX you have the console option, yes. But it only enables sending strings on the serial port.
  • Create New...

Important Information

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