Jump to content

Michael Aivaliotis

Administrators
  • Content Count

    6,156
  • Joined

  • Last visited

  • Days Won

    91

Posts posted by Michael Aivaliotis

  1. I will complete the survey but wanted to add here as well. I use EtherCAT primarily with 3rd party slaves and only use NI hardware\software. I have limited time resources and prefer to stay within one environment, so I choose NI software whenever I can. I just don't have time to learn all the 3rd party tools. Maybe others can help me here. if anything, at least this thread has brought other ECAT¬†experts to the surface, I can DM for help ūüėČ.¬†I have come across a few limitations but I have been able to work around them because I have no choice.

    One thing that is frustrating is there is no way to define a topology with NI tools. I'm sure there is an algorithm that defines this under the hood, but it's not controllable by the user. If you have a daisy-chain setup, then it follows that, however if you add a switch to the mix then I have no clue how it's determined. This is critical to the software development side since device IDs matter and they change. If you pull out a device from the chain, then the downstream device IDs change. this can get frustrating from a configuration management perspective. Device IDs are settable on some 3rd party devices with physical switches but the NI tools cannot query these IDs for some reason. This would help make the topology a little more predictable. Another limitation I ran into recently. FOE is not fully supported. FOE WRITE is supported but not FOE READ. I think in general the ECAT tools need a higher level API that can be used within LabVIEW. For example, the EtherCAT Library for LabVIEW from Ackermann Automation is a good example. It seems NI put in the bare minimum required to meet the standard and support one or two of their own hardware with little consideration for third party devices. As others have posted, basic error handling on faulty ESI files should be baked-in.

    • Like 1
  2. I get an error 7, file missing error when I run the app builder Build.vi provided by NI (visible in the palettes).

    Quote

    NI_LVConfig.lvlib:Load.vi<ERR> C:\Users\MichaelA\AppData\Local\Temp\AB_Cache_{DD695C27-7E5F-4A88-8B25-B389D65799CC}.txt <b>Complete call chain:</b>      NI_LVConfig.lvlib:Load.vi      NI_LVConfig.lvlib:Open Config Data.vi      AB_RW_Project_Cache_Info.vi      BuildMonitor_Clean.vi      CleanTarget.vi      NI_App_Builder_API.lvlib:Clean.vi      build exe - vishots.vi      Build_App2.vi

    I've seen this issue a few times with various projects. I'm not sure what causes it, but there's no way to recover from it quickly. The only thing that fixes it, that I've found, is to manually execute a build from the project build spec. This seems to fix the missing cache issue. After a manual build is done, Automated builds using the build.vi work as expected without errors, multiple times.

  3. I've been trying the "save for previous" feature in LabVIEW. It gets stuck in this dialog and LabVIEW just freezes and I have to terminate it. I was down-saving a VI that was part of a class and it called a couple classes as well. So it wasn't just a single VI.

    Screen Shot 2020-08-01 at 12.22.07 PM.png

    Does the "save as" really work? Curious if others have success with this feature.

  4. On 7/3/2020 at 10:43 AM, Jim Kring said:

    Thanks for helping everyone out. Older versions of VIPM are available to users -- we have a link on the vipm.io/download page for users. However, since older versions of VIPM use outdated LV runtime engines that are longer be supported by NI and don't work well on newer OS'es, we don't encourage users to use them -- it often creates more problems for them, and a support burden for JKI and NI. As such, we ask that people do not post older downloads and instead direct people to get them from either NI or the VIPM websites. Again, thanks for helping people out.

    Can you provide a public link where people can download VIPM 2019? So far I haven't seen one, unless I missed it.

  5. On 6/23/2020 at 7:24 AM, Mads said:

    Is it seriously based on people having to use the command line to install packages?ūü§¶‚Äć‚ôāÔłŹ The main selling point of LabVIEW is that it is *graphical*....and it is trying to force everyone to use the command line??

    I know there is a GUI for it, I've seen it. But the marketing for it, does not promote it anywhere. I wish I could quickly point to where that is, but unless it's accessible from the homepage, you lost me. If you take the philosophy that GUIs are not for real programmers, then you will start to align with GPMs design language.

  6. One thing that I was pleasantly surprised by, in the video presentation. Was the announcement of a 6-year partnership (not sure what that means) with the FIRST robotics organization to provide hardware like the roboRIO. I was almost certain that NI abandoned this effort years ago. It's nice to see them reaffirming this relationship. Proof is in the actions, so we'll see. I hope this means more active support to the teams in regards to promoting LabVIEW and not just, ya we will keep selling roboRIO.

  7. So just adding info here for future googlers.

    There is an NI KB article on how to cleanup the cache here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KdtSAE&l=en-US

    In there it also mentions an ini token that eliminates cache creation completely:

    Quote

    you can add a token to your nipkg.ini to prevent the caching of packages in the future. The nipkg.ini is located at \%localappdata%\National Instruments\NI Package Manager\nipkg.ini.

    Make sure you add the token below the [nipkg] line so it looks like:
    [nipkg]
    cachepackages=false

     

    • Like 1
  8. Right, if running LV community, you have everything you need. No need to install anything from VIPM. In fact it will make it worse.

    The reason why the log message states Raspberry Pi 2 B (I stated elsewhere), is because the LINX toolkit has an old hardcoded message internally that does not trigger off the actual board model. @Darren, this should be fixed becasue it's confusing.

×
×
  • Create New...

Important Information

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