Jump to content

Leif

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

0

About Leif

  • Rank
    Active

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since
    1997

Recent Profile Visitors

930 profile views
  1. Thanks Eric! This is (probably) what I was looking for. However, when implementing some features, I've found that my child classes cannot have any attributes or class unique methods. But in my applications that shouldn't cause any problems; attributes are only relevant in the parent class AppBuilder (project file, build spec name...) and I can't see any need for specific methods in the child classes. Is there a name for this kind of class? (This feels a bit like "The Man Without Qualities"...) As I'm using GOOP, all classes are created with a default attribute, so I have to delete
  2. Well, that's a completely different approach and it could work if I adapt it to my application. I'll have a try. Thanks! But I'm still curious if there is a solution where you can create objects from specific child classes (e. g. AppBuilder 2015) in runtime, without "revealing" them in "compile time". Unfortunately, two pieces of code dissappeared when submitting my post: This is the principle I want to use, but it makes this VI broken. I have tried using Get LV Class Default Value.vi, but I can't connect the object wire to my AppBuilder VIs. Is there some way to cre
  3. I'm working on a project for building applications (*.exe) and installers (setup.exe) from LabVIEW projects, that should work for different LabVIEW versions. As we currently use LabVIEW 2013 and 2015 (and soon 2017 I guess), my "framework" (GUI, state machine etc) is developed in LabVIEW2013. When I want to build application and installer from a 2013 project, I'll run this framework in LabVIEW 2013, etc. When building from a 2013 project, I have to use Application Builder in LabVIEW 2013 and when building from a 2015 project, I have to use Application Builder in LabVIEW 2015, and so
  4. Shaun, I really liked your solution, so I made an implementation; attached VI (LabVIEW 2016). Get SVN info.vi
  5. The class diagram has evolved and grown: Let's investigate a case where Test Case is using Thorlabs OPM to test an optical power. This OPM is connected with USB. But I also want to emulate this OPM with some software where command responses are defined in a text file (used by Response File). Each file should be device (class) specific. In the final application, the execution would look like this: USB calls Thorlabs OPM (buildCommand) where Thorlabs OPM builds a string (commandString) for requesting the OPM power. This string is sent over the USB bus to th
  6. Realised that Operator GUI is not an emulated resource as it could be used to connect to the actual hardware. Then the class diagram should look like this:
  7. Thanks for the comments, hooovahh. Maybe, I'm not using good class names. I've got the feeling that e. g. Digital Multimeter more represents an interface to the device, rather than the device itself. Sometimes we have like ten different hardware classes, so creating an emulating/simulating class for each makes the whole project filled with duplicate classes, where the emulating classes almost have the same functionality. This is why I want to avoid this solution. As you mention hooovahh, I could use a boolean to indicate whether to use an emulated the hardware. However, I also w
  8. I often find myself in the situation where I use a number of hardware devices in my application. The communication interface could be USB, RS-232, Ethernet... When developping and debugging the "execution logistics", it would be so nice if I could emulate the hardware, but I can't find a good solution/architecture. Probably, there are lots of intelligent developers here that could help me. Without the emulation option, the class diagram would probably look like in the picture. The most basic emulation could be having a GUI displaying the command sent and a manual entry for
  9. My test group has decided to start using OOP (beyond LVOOP I hope). The question is should we use an OOP tool and which one: GOOP/GDS or G#? I'm quite biased as I have used GOOP for a number of years, but I'm trying make fair investigation. I also realize that the StarUML plug-in in G# could be very useful. Has anyone made or seen a comparison between GOOP and G#? Or do you have an own opinion? (Searching for the text "G#" isn't that easy...)
×
×
  • Create New...

Important Information

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