Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/24/2012 in all areas

  1. I made this test VI to show what I have. It seems I always get "one parent up" when I embed subpanels within subpanels... Weird. http://screencast.com/t/jNX95hOCFS (LV2011) DropVIContent_PaneUserSelection.vi
    3 points
  2. UDP is not a reliable protocol. Unless you intend to do A LOT of extra error handling, packet sequence management, lost packet retransmission and what else, you can forget to use it for transfering a file that needs to stay consistent.
    2 points
  3. It seems that NI is in the process of developing drivers for IEC-61850. http://forums.ni.com/t5/LabVIEW/IEC-61850-and-IEC-60870-5-103/td-p/1868231#M633636 Maybe you could contact your NI rep and get more info or help them test their driver..
    1 point
  4. You haven't shown much so far that would have made me believe that you have much of a technical understanding of those protocols. And wanting to do something is a nice thing, but if it is a useful exercise an entirely different one. Considering some notices in the paper about how the difference in calling socket functions can have a significant influence in lost buffers, I think LabVIEW might be not the ideal environment to tackle this research. You have no control whatsoever, in how LabVIEW handles the socket calls. In addition it adds it's own network data buffering that you can only influence in limited ways from the LabVIEW nodes. And no I'm not talking about controlling socket attributes by calling socket API functions directly, but how LabVIEW calls recvfrom() and friends itself.
    1 point
  5. To me it looks like IEC61850 is not about transfering large files consistently over the network. To do that over UDP is really not a smart idea as you have to implement on top of UDP something similar what TCP does already for you. An interesting side node to this: A while back I was looking at the network protocol used by Second Life and other compatible virtual world environments. They used to have the entire communication over UDP with their own sequence handling, acknowledgement and retransmission requests. The reason to go for UDP was supposedly the low overhead that was required to make movement and interaction in a 3D virtual world possible at all. However a few years ago they did introduce a new mechanisme for non-realtime critical messages and are porting slowly more and more of the messages over to this new mechanisme. It is basically a HTTP based protocol where the packet load is usually a data structure in their own LLSD format, which is in many ways similar to JSON. And yes I have implemented some basic messages in LabVIEW that got me as far as logging into a virtual world server.
    1 point
  6. Here's a solution to fix the finicky dragging. Instead of trying to make the window a certain size and dragging it around, just drop a graph control and make everything transparent, but leave a green cursor. The image below shows the cursor overlaid over an Excel graph. The cursor makes the dragging really smooth. If the graph is set to fit to pane and the window set to maximized, I think you'll get the behavior you are looking for.
    1 point
  7. Decided to Google IEC61850 and UDP. I found this interesting PowerPoint presentation in PDF form. http://www.pes-psrc....%2002282012.pdf I liked the next to the last slide best: The author indicates that dropped messages are statistically insignificant. They were never able to eliminate them completely. If you're just starting out with LabVIEW, this is going to take you some time, and I would wager that you will never achieve zero data loss using UDP.
    1 point
  8. Here's a link to Ram's presentation and examples, where he shares a lot good stuff about XControls. https://decibel.ni.com/content/docs/DOC-21551
    1 point
  9. I added the info to the LabVIEW Wiki page on XControls
    1 point
  10. Thanks to Ram Kudukoli (of NI R&D) for sharing this with us at the recent CLA Summit: If Façade is not executing fast enough to keep up with data updates, it causes the updates to queue up. The updates will happen even after the VI stops running. To reduce data updates: - Open the Xcontrol .xctl file in a text editor like Notepad. - Add the bolded line shown below: <Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property> <Property Name="NI.XClass.Flags" Type="Int">0</Property> <Property Name="NI.XCtl.OptimizeDataUpdate" Type="Bool">true</Property> <Property Name="NI.XItem.DeclaredLeakProof" Type="Bool">false</Property> - Save the .xctl file.
    1 point
  11. I've not come accross Quad-tree but I have come accross R-Tree
    1 point
×
×
  • Create New...

Important Information

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