01-22-2015 02:44 PM
St3ve wrote:
Hi,
A couple of questions:
- Would it be possible to have an optional input, of the class type on the constructor i.e., on the polymorphic <Create Modbus Instance.vi>? This way users would be able to sub-class the master to wrap up device specific behaviour.
- Is there any reason for the locked block diagrams? It certainly helps when debugging to be able to look inside.
Thanks,
Steve.
1. The polymorphs were for ease of use so there is no input for users to select -- it was intended to simplify the code for people with less familiarity with OOP concepts. Nearly everything in the codebase is a plugin and you are welcome to copy one of the constructors and modify it for your particular device, or class of devices.Those diagrams should not be locked, and I'd recommend taking a look at them to see how they work.
2. Someone has asked this question on almost every page of this forum and I've never made anyone happier with my answer. Short version is that its locked for the same reason some code in vi.lib is locked, and the code is going to stay that way. Sorry.
01-30-2015 02:36 PM
Didn't read through all 18 pages of this post, so I'm not sure if this has been covered somewhere else already. We use the NI Modbus API v 1.1.5.39 on a pretty regular basis and I usually create my modbus drivers by inheriting from the Modbus Master.lvclass. However, this is a pain currently because I've had to create my own version of the Create Serial Master or Create TCP Master vi's so I can pass my own child master object in. Any thoughts on changing this in a later version, I'd really like to be able to use a supported version of the library without having to kludge in my own stuff and rev it each time along with the library.
01-30-2015 02:44 PM
I guess I just needed to look back one page, sorry.
I saw your post on the previous page about creating our own librarywith the polymorphs in it, which I've done. Just wanted to have something that I didn't have to worry about reving along with the modbus library. I think if you added a class input and made it a non-required input and than handle an empty input appropriately you're not forcing the non-OO guys to learn OO, and you still enable those of us building children classes of the master of slaves to pass our own class in.
01-30-2015 05:05 PM
That could work. Thats basically what is done with the data model, although that has only one default rather than 4. I am curious what you're specifically doing when you wrap it. The way I see it, the instance represents only the protocol layer and so you wouldn't wrap it, you'd have a "device" class each containing its own master instance. On the slave side, this is what the data model does -- it doesn't change how the protocol works, it just changes what the protocol interacts with. Can you clarify what you're doing with your child classes?
01-30-2015 09:38 PM
Typically I create the device class as a child of the master. This enables me to create specific methods for interface with the device, but still allows us to call low level API for engineering or debug. I can share some code if you'd like so you can see what we're doing with it and maybe even offer some guidance if we're not using it as intended.
By the way, other than the constructor, which is a minor issue in my book, I'm really happy with the library. I'd love it if more of the NI produced library's were built with OO concepts.
02-03-2015 09:45 AM
Glad to hear the library is working out. I think it might be feasible to do as you suggested but I think it would break the current interface (I'm already using top left on the connpane). Still, I'll keep it in mind next time I break out the VM. The other thing I was considering was trying to prefix some of the class names in a way that it would avoid crosslinking issues with the primary library in 2014. Ideally, people would switch directly to the official library but there are some situations where that isn't feasible.
02-03-2015 12:25 PM
Sorry, when you say 'official' library do you mean the one that ships with DSC module? What are the differences between this library and that, and will this library become unsupported? Tough to get the boss to pay for the DSC module for a single piece of functionality.
Not to jump on the anti-password bandwagon, but if this library get's obsolete'd in favor of the DSC module's implementation, it would kind of suck if it wasn't a community project that we could then support, similar to the AF.
02-03-2015 02:54 PM
I'm personally on the anti-password bandwagon so I mostly agre. However, a counterpoint I've made before -- being devils advocate -- is that AF was open sourced on github here (https://decibel.ni.com/content/groups/community-source-of-ni-code) and in the last year there have been 0 community contributions. I realize there is a difference between letting people tinker with their own custom version and the collaboration mechanism enforced by the github repo, but at the same time its not great to have everyone with their own custom version of the code.
As for "official", yes, I mean the DSC/RT 2014 release. This NI Labs release will remain here to allow people without RT or DSC to use this library without having to use the older (~lv7) library. This release will remain supported by me as much as possible, but it is not my primary role. The DSC/RT 2014 is similar but there are some small code differences, better documentations, and it is officially supported as a product.
02-04-2015 12:58 PM
From some basic testing done over the past few days I've been able to isolate my problem to the serial buffer not being properly flushed on close, and not being fully read (apperently) each read.
Here is a sample of the code I've used to circumvent this persistant and painful error. Often times errors wouldn't be thrown until 5 minutes to 3 hours after the software was started.
02-04-2015 01:59 PM
Interesting, the buffer should be flushed automatically when a new object is instantiated, specifically in vi.lib\NI\Modbus Library\Serial Shared Components\Configure Serial Port.vi
What does the wait timer do in this situation?