After the presentation they encouraged questions, so I asked how the open source was to be operated, there were some very embarrassed looks among the speakers and one guy took the mic and explained that they had decided not to release the software as open source, when I asked how they could guarantee that PactWare would not become another vendor lock-in tool he couldn't answer me.
The demonstrations of the software itself were quite mediocre, With the rise of IP addressable sensors and peripherals with configuration using built in web-servers, it is an idea which is probably past it's time anyway.
I guess the general idea is to give it away... to begin with. A really big shame and a missed opportunity to make a change in the industry.
In reply to Marc Sinclair: Your response was interesting, so I had a look at the Pactware link you provided. The software comes in two parts. There is the main Pactware package itself, plus you also need "DTM" software to communicate with the equipment.
They have a paragraph on their web site which states: "DTMs are available from the respective instrument manufacturers. Many manufacturers offer free-of-charge versions with slightly limited functions as downloads."
So, it sounds like the idea is to give away the actual Pactware software, but to charge for the part that you need to actually talk to an instrument.
I had a look around at what the license terms are. The license only allows you to run the binary and expressly forbids decompiling or disassembly. So, it sounds like their "open source" claims are bogus and meant for PR purposes.
Well, I'm not sure what to think about that. I downloaded PACTware and Endress and Hauser's DTMs and have tried it on a couple of there instruments with success. I have also learned that FieldCare, an E+H FDT program, is very simular to PACTware but has different versions from open sourced to big bucks. Their free version just uses their DTMs but the bigger brothers can use E+H's iDTMs, which are DDs and EDDs converted to DTM. I'm not sure how well they work, but I have talked to a friend who has, and it seems to work.
As for the rise of IP addressable sensors and peripherals, I have not seem that in the Industrial world in western Canada. Most still use convential instrumentation and I have come across some Fieldbus. From what I have seen and used (HART 375), PACTware or FieldCare seems like a great tool to have. Even since I seem to have PACTware and some manufacturers DTMs free, it looks like i'll have to spend some money if I would like to have iDTMs for the manufacturers that use DDs and EDDs.
PACTware and DTMs are based on FDT [Field Device Tool] technology. The FDT standard is entirely open and the specifications are freely available [http://www.fdtgroup.org]. I believe the communication functions [within the Windows environment] use XML and COM components internally.
The manufacturers providing DTMs and applications have agreed to use this open standard [FDT]. It is more complex than simple markup text because it needs to be to have the functionality desired for complex environments like modern control systems filled with intelligent devices.
I will submit another post to this thread describing FDT and PACTware a bit more.
PACTware is a "frame" or "container" application that supports the Field Device Tool [FDT] interface.
FDT essentially partitions the PC-based software system into separate component types, the frame or container application, and device type managers [DTMs] with defined interfaces between them. Device type managers encapsulate device or communication protocol specific logic into driver objects; FDT specifies the interfaces between these objects. A frame application (such as PACTware) instantiates the objects (including displaying the device user interfaces) and allows connections between them.
The functionality specific to particular devices exists in the devices' DTMs (which can be arbitrarily complex, for example with graphic elements showing waveforms, trends, histograms, upload / download of data sets, firmware updating features, etc.).
PACTware itself is a relatively simple application; it exists mainly for those PACTware Consortium member companies who do not develop control systems or engineering tools to be able to provide their customers with a means to interact with their products (e.g., transmitters and actuators) at little or no cost to the end user. More capable FDT-based applications are readily available from most leading control system suppliers (including Yokogawa, Honeywell, Invensys / Foxboro, ABB, Rockwell, etc.).
Even so, PACTware (available at no cost) with various device DTMs (often available at no cost) is a more powerful tool than some comparable solutions that cost hundreds or even thousands of dollars.
Regarding openness, the FDT standard is entirely open, the specifications are freely available [http://www.fdtgroup.org]. PACTware is "open" to members of the PACTware Consortium; full members have access to source code. (This is "open" like industrial communication protocols are "open"...). However, you can certainly make your own components [DTMs] that interoperate with PACTware, or make your own frame application because the FDT standard is open and available.
P.S. Additional comments regarding FDT technology: it achieves higher levels of vendor independence and field communication protocol independence than virtually any comparable standard in the process control environment. Advocates for Device Description [DD] based systems claim that DDs have superior portability, but that technology will never have the wealth of functionality that FDT already has.
Central to the Field Device Tool concept is the separation of device parameters and communication functions and "frame applications" into distinct modules. This provides real flexibility to end users who can easily add software components and devices from different manufacturers to their system, even using different communication protocols. Or conversely, use software components associated with devices (i.e., DTMs) with any of a number of different host system environments.
And because FDT has defined the system with communication elements as modular components, arbitrary protocols and hardware interfaces (including proprietary communication schemes) can be added to FDT-based systems by creating a communication DTM. For example, an FDT frame application could have support for any or all of these protocols: HART, Profibus, FF, Modbus, Interbus, and various proprietary protocols, by adding the associated communication DTMs and corresponding device DTMs.
I could then design a plant with the BEST devices from multiple manufacturers and use ANY program on ANY platform to collect the data to be used by ANYONE, anywhere, now that's open.
I'm not against any manufacturer producing the bloatiest, dumbed down software, bristling with graphs , wizards and widgets, but when I have to use a certain OS, on one type of machine, buy and connect an interface unit, buy and install 400MB of program to set a simple 0-100% level sensor - For each manufacturer - I despair.
It appears that we are discussing very different things.
Technologies like FDT are addressing much more difficult challenges like advanced troubleshooting and diagnostics, instrument management, etc.
Standardized basic setup like you describe has been available for about a decade in the form of HART Common Practice commands. A single command (Command 35: Write Primary Range Values) allows you to set the range of any of hundreds of different devices (almost every device that supports HART).
Thanks. So using the FDT program PACTware for bench configuring and maybe a little field troubleshooting is not a far fetched idea. The only problem would be finding the DTMs (iDTMs) for the devices that use DDs and EDDs, silly Rosemount! If I could find these iDTMs like the ones Endress and Hauser developed for there Fieldcare (another FDT program) I would be a vary happy little Instrument Mechanic!
As they state, "The iDTM interprets HART DDs/EDDs (FOUNDATION Fieldbus and PROFIBUS to follow) and enables the integration of third party HART devices without dedicated device DTM into a FDT frame application". (I have not tried this DTM myself).
And PACTware usually comes bundled with a HART Communication DTM and also a Generic HART Device DTM which provides basic setup capability (e.g., loop setpoints and damping value), and display of measured values and device status.
Full-featured DTMs are widely avaliable from many companies (as you mentioned, Emerson / Rosemount is a notable exception).
There is nothing (digital) that any program can do that can't be communicated to and from the device using a mark-up language. As bandwidth is not really an issue, and processing power is almost free, there must be another reason that it isn't used. The benefit of using a simple readable communication would be that anyone could interface any data to any program on any platform. Anyone could write set-up and diagnostic software in any language on any platform under any business model.
I'm sorry if I've wandered off topic, I suppose my main problem with PactWare is that I just get upset at adding another 'middle man' to MY business.
I have been to PACTware site, downloaded the application (from a members site) and have had success learning how to use it with the E+H instruments I have to configure, verify and install.
I like using the application for a couple of reasons, first the informations is easy to look at and second, entering data like the range and descriptions is alot nicer than the 375's little style (i think that what it's called).
I have tried to contact Codewright for info about there iDTMs but i'm still waiting.
I would like to thank you both, Marc and Chris, and it is clear that your both are as control.com says, Nerds in control.
Happy I found this site,
Winnipeg, Mb, Canada
The 375 and PC software are two different things (outdoor vs. indoor) so in my opinion they cannot be compared. My Outlook is a lot nicer than my Blackberry. See what I mean? The beauty of the Blackberry is its portability, not its small screen.
The 375 is PORTABLE in a way that a laptop isn't. When work is done in the field, a laptop is not very practical. Too heavy to hold with one hand. In the field there is no place to put it. Touchpad is hard to use while wearing protective gloves. Not intrinsically safe. Battery not lasting one workday.
A handheld field communicator is small, can comfortably be carried a whole day. You can hold it with one hand a long time. Rugged design (no moving parts like hard disk or fan and no ventilation holes). All-day battery-capacity so there is no need to leave the job unfinished due to running out of battery. Touch screen and large stylus works while wearing protective gloves.
Bus technology has reduced, but not eliminated, field work. Field work is inevitable. A lightweight handheld field communicator is the technician's best friend.
A laptop is great in the workshop though. Since there were also some remarks in this same thread implying EDDL is limited, I also want to mention that there is PC software from different manufacturers with large screens and millions of colors out there using EDDL. You can see some of them here: http://www.youtube.com/wwwEDDLorg
I do agree with you on all your points and I do have a 375 in my bag. My info seeking about this is more for learning something new. however, using it in the shop has been nice as well as seeing the envelope curve for my ultrasonic levels. As for the intrinsically safe, wouldn't that be thrown out the window as soon as one opens the instrument's enclosure?