Jump to content

todd

Members
  • Posts

    335
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by todd

  1. Can't find the diagram, but I used composition for communication with a family of devices. Device class contained "transport", "firmware version", "key map", etc. Transport (serial VISA, FTDI dll, custom .net dll) had read and write methods - no abstract parent. Firmware Version parent class had specific functions (one per Byte, kind of thing) for version 1. Version 2 inherited from version 1 - some overrides, some extras. Version 3 inherited from version 2, etc. Key map turned scanned ADC arrays into other things. It worked very well, even at six firmware versions. Selection of each type of object was done via enum/case statement. This allowed direct selection and trial-and-error detection of each object in the device.

  2. Prefixes -> Use libraries/classes instead (you'll get a namespace 'Library.lvlib::Member.vi'), how would that look with prefixes: 'prefix_Library.lvlib::prefix_Member.vi' ( :nono: )... You have to organize the files on disk to prevent name conflicts though. If there is a need to prefix everything, just change the library/class name (linking issues are conveniantly easy to solve this way in my experience).

    "Me, too", on this one. lvlib for namespacing and encapsulation. Short names for each class and method. One file-system folder per class and it's methods. Virtual folders for grouping by functionality within classes and libraries.

    • Like 2
  3. After modifying Jack's EventsAndSundry vi #02, I must amend my statement on the NI forum. If a dynamic event is registered but not handled, that does not directly cause a leak. The leak starts if either: the loop in which the event structure resides stops; or the event structure handles events slower than they are generated.

  4. If I understand what was described above, this may be a useful data point.

     

    In 2013:

     

    fpga.vi writes data to a typedef cluster indicator

    rt.vi reads the fpga's typedef cluster indicator and writes a psp variable of the same type

    pc.vi reads the psp variable

     

    If the RT build spec has "Disconnect type definitions" selected, everything works.

    If typedefs are not disconnected, the RT's psp-write does not put data on the network.

  5. My experience is, that in almost every case the IDE is unstable because the sources are not very well designed (see discussions regarding code complexity & dependency trees). So I think as NI should work on stability and performance, we have to work on our own sources to solve bugs and decrease code complexity.

    Yes, the IDE is stable until a user does something less than ideal, So instead of a user having to learn what will work, perhaps the IDE can teach us what won't work. Perhaps show the user what's taking so long.

    • Like 2
×
×
  • Create New...

Important Information

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