Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/05/2016 in all areas

  1. Hello I recently started learning Labview and I just got my CLAD. My special thanks goes to Hooovahh and all the community Yeaaaaaaaaaaaaaaaah
    1 point
  2. Thanks for taking the time for review my code! I was originally thinking about doing something fancy with the PDU inside of the ADU but decided that it was better to let the PDU deal with itself. I agree there is no reason to have it in the ADU class. The simplification that I made to the RTU serial read was to cheat by having the "build PDU request" function calculate the expected number of data bytes of the PDU response. This way the RTU serial read procedure doesn't depend on timeouts or the function code. The downside of this is that when implementing new function codes, you need to remember to set the NumBytes parameter of the PDU request properly otherwise RTU serial read will not produce the expected response. This is why I was tempted to encapsulate the PDU in a class instead of a cluster. However, to make it easier to add functionality, I agree that it's a better idea make the PDU a cluster. Implementing a new function code is simply a matter of creating a VI that calls Querry.vi with the correct parameters. I've prepared an update with the following changes: Converted MB_PDU class to cluster Removed RTU inter-frame wait time optimization in TX ADU. It may have caused problems when sharing the serial port. Renamed NumBytes of MB_PDU to RTU_DataBytes Split interpret response VI of PDU into 3 VIs to handle different message types Set build and interpret VIs of PDU to private Removed function VIs from MB_Master class Removed PDU_req and PDU_resp from the MB_ADU class
    1 point
  3. I would think it should look something like this. I've not tried running this... You will need to ensure all children you want as children of the inserted class are in memory before running this, though I believe anything in an open project is in memory. I hope this helps!
    1 point
  4. Assuming you have an easy way to get all the child classes into memory, something like this should do the trick:
    1 point
  5. The exact details of when the exact clone is exactly "reserved" do vary for many reasons. It's not necessarily deduce-able from the diagram since the compiler tries to optimize things. The caller VI might grab a clone once and hold onto it for a while or it might grab it exactly as it needs it. And yes, SD versus DynD also play into this. Dynamic Dispatch I believe is always grabbed at the last minute because we have to deduce the right VI to call and it might vary between loop iterations, etc.
    1 point
  6. "Shared Clone" reentrant subVIs are assigned to a callsite from the pool of free (not currently being run) clones *at the last minute*. This means that generally if you go click on a callsite, LabVIEW can't possibly know which one will actually be run by the caller VI, so LabVIEW just opens the "master copy". However, if that callsite DOES have an assigned clone because the clone is running exactly when you click on the callsite, then LabVIEW can open the right clone! This can be very hard to do unless the subVI takes a long time to run or you are already debugging thanks to hitting pause or hitting a breakpoint or stepping.
    1 point
  7. In the later LabVIEW versions, one can open the original copy and select View>>Browse Relationships>>Reentrant Items, and that allows one to open the shared clones. In older LabVIEW Versions, one can (temporarily) set the VI to "show front panel when calledâ€. However, if your building a message-based architecture, you can just build in a “show front panel†message to your actors/processes/modules/whatever.
    1 point
  8. Everything works now, here's what I've learned: LabVIEW is using a list of trusted authorities from the file: "%ProgramFiles%National InstrumentsSharednicurlca-bundle.crt" If your Certificate Signing Authority is not in that list, you will receive Error 363507 - LabVIEW could not verify the authenticity of the server. In order to avoid this error, either find a new Certificate Signing Authority, or you can specify your own Trusted Certificate Authorities using ConfigSSL.vi (shown in the screenshot below). When you distribute your application, ensure to include this file with the distributable. When you download your certificate from your CA, through the management console you can probably also download the Root Certificate of the CA -- this is the file that you wire into CA certificate file of ConfigSSL.vi. (This file might even be included as a zipped certificate bundle when you download your cert.) This file will look like the following if opened in a text editor: -----BEGIN CERTIFICATE----- MIIFB...LinesAndLinesOfBase64....== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIED...LinesAndLinesOfBase64....== -----END CERTIFICATE-----
    1 point
×
×
  • Create New...

Important Information

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