Jump to content

Michael Aivaliotis

Administrators
  • Posts

    6,196
  • Joined

  • Last visited

  • Days Won

    103

Everything posted by Michael Aivaliotis

  1. Is this error message coming from a VI that you are running on the RT target? Have you tried using the NI Distributed System Manager? I use that to debug Ethercat issues. When you switch to Active mode using NI DSM, it works pretty consistently. Unfortunately the NI Ethercat driver is a load of poop. Soft reboot of the controller usually fixes things up.
  2. I have no idea. That seems to be a URL in the old format which died a log time ago. The post probably still exists but was converted to a new URL format and there is no redirect.
  3. What happens when you create a page? Do you get an error or something?
  4. Thanks for the interesting conversation. I've resolved the issue however, in a roundabout way and by cleaning up my code. The UDP communication code in question is a model written in LabVIEW running on VeriStand, which is essentially a bunch of LabVIEW RT timed loops running on a Phar Lap target. So the model essentially opens a UDP connection, sends the message, then closes the connection. This is done at a rate of 50Hz. I changed the code so that it opens the connection at the start of the test and the model just continuously sends the message at the 50Hz rate, then at the end of the test I close the UDP connection. This resolved the issue because now the ARP is not sent anymore, like at all. Well, maybe at the start? But I haven't checked that, so I should do that later. The explanation I can come up with is, I was closing the connection every 20ms, so the OS considered the port closed, so it took that time to do the normal housekeeping of sending the ARP? But since the port was always open to a known IP address (and thus mac ID), it didn't need to do the ARP. I don't know, just my guess. Ok, so bring on the comments about, why I would keep opening and closing the port. Bring it on, I can handle it... 😀
  5. Looking at this post by an NI employee. It seems that the ARP table cannot be statically defined on Phar Lap.
  6. I'm using LabVIEW to do all this. So not sure how to do RUDP. I'm using UDP because of the low overhead. But maybe I can still get the throughput with other methods. I will have to experiment and see. I've just never considered that this issue would come up at the slow rate I'm using. Edit: It seems like ARP has a configurable timeout. Since my test only lasts for about 2hrs. Perhaps i can do an ARP at the start of the test and set the timeout longer than 2hrs. Now to figure out how to configure this timeout in Phar Lap.
  7. I have LabVIEW code on 2 separate PCs using UDP to send data. It's a one-way path from a LV RT Pharlap Target to a Windows10 receiver. I'm streaming data at a rate of 50Hz and I don't lose any packets. I have confirmed this with Wireshark. However, every 15min. the sender sends an ARP packet instead of a UDP packet. This lost packet is critical to my process and not acceptable. Is there a way to turn off ARP or change the timeout of it to something longer than 15min? I realize I need ARP, or do I? Can I just update this magical table manually? Info on ARP from Wireshark.
  8. So it seems Bitbucket has some solution for this actually. I think Github as well. It's called LFS (Large File System), and it manages large files outside of the repository. Here's their tutorial: https://www.atlassian.com/git/tutorials/git-lfs You just have to specify git lfs track '<pattern>' This can be a folder, file wildcard etc as explained in the docs. I think released installers should not be versioned. It doesn't make sense, and is not very convenient, to revert your entire repo to a tag, just to send someone the correct version of the installer. So I definitely think those files are candidates to be off on dropbox. The space on dropbox is much cheaper than the space on Bitbucket, even if it's using LFS. But LFS is useful if you can't predict which files will be large, such as a support folder that should be versioned. For example if it contains build support tools or parts of the installer build support etc. These need to be versioned in case they change throughout the development cycle.
  9. I use tags as well to mark where a new release version is built. This way I can go back to the tag if I need to branch, to fix a bug on that version or to track down a version related issue. I'm in agreement. Whoah. 10Gb is definitely larger and would basically solve my problem. More than enough (famous last words). However, a lot of these decisions are also related to the surrounding ecosystem of tools. Bitbucket surrounds itself with Atlassian products which I love and use. I previously switched from Kiln and the main reason is not so much the repo management but the surrounding tools were out of date and not getting any feature additions or development support. I just like having everything under one umbrella. Ya, I'm already aware of the tools and already have an automated build process in place. I was just hoping to skip this work. But in the end I will do this of course. What else can you do.
  10. I'm currently using Bitbucket, but I've used other cloud services and have used GitHub as well. The ones I've used have limitations and typically cap your repo size at 2 Gb. Recently I hit this limit on a large project. Mainly because of all the support files. However if you've worked on any large LabVIEW project that has constant development for a decade, then you can probably hit this limit considering the binary nature of LabVIEW source. So this question is mostly to get community feedback on what approach you use to handle this, if at all. I went down a rabbit hole recently on one big project. I decided to keep ONLY source code in GIT and move all support files to dropbox. I also tried putting the build output and other transitory files to dropbox as well. However I found an issue because dropbox would interfere with the build process (any insight to this from others is welcome). Thanks for your help.
  11. I was able to change your username to Bryan.
  12. Hey, sorry, just saw this. I'll see if i can change SouthPaw to Bryan. The Wiki admin stuff is not as sophisticated as the one here on LAVA and they are not connected either. Let me see what I can do.
  13. Stupid question. Why don't you open a file handle once then just keep the file handle open while writing, then close it at the end of the program? When you write to an open file handle, the file pointer stays at the last write point.
  14. In this last post of the working snippet. can you explain how you added the image/snippet? I can't seem to reproduce your embed process. When I add an image it adds it and the name changes with an appended hash. it also changes the behavior so when you click it, it pops up in a viewer window. However, with your embed, the image retains its name and clicking it does nothing.
  15. Can someone point me to an online post with a working snippet? On LAVA or elsewhere.
  16. I haven't seen this on program stop. However, I have seen it on program start in a clean environment. It's probably not related to your issue, but it's specific to one project only for me. I was in contact with NI and the only way for them to solve this is to send them the whole project.
  17. So the main problem is getting the installer build script to get updated with the correct EXE build. I wonder if there's a way to signal that change to the installer script. I've never seen this issue. However, I usually just programmatically run the installer build script right after the EXE build script and it works every time. Do you have the project open while doing all this?
  18. I think you'll get better support on that over in the NXG support forum.
  19. In the LabVIEW options. If you toggle Automatically close VISA sessions, on or off. Does it make a difference?
  20. In current gen? Well, that's a different problem. You could elaborate on that in a separate thread and we could help.
  21. Yes, I remember when this feature came out. I was very happy about it. Then I foolishly trusted it. Then I discovered a bug in this feature by accident. The auto-mutation failed. So now I was burned again by a feature that I was suppose to trust to solve the original problem. You see why I'm shell-shocked.
×
×
  • Create New...

Important Information

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