Patronizing, I'll have to look that up in a dictionary . I would have preferred the words philosophical, pragmatic, etc. I assure you
that if you reckon your scope of options is limited then you should try my home ground which probably has only 1/20 the options offered in the US of A. Again I believe you are making the exercise of interfacing appear more difficult than it need be. For example, you indicated that you had to develop a protocol that would allow the
devices to work together. Well thankyou for just introducing another protocol to the world - it is not as though we don't have enough to support. Why didn't you adapt - go to the web and download a simple already existing protocol more widely accepted one than yours (JBus for example). Now if your client wishes to add another device they will have to interface to your protocol, who is going to write the interface for them .

Even reverse engineering is not really that difficult and done properly can offer additional benefits to the client. A quick example we had, a certain German engine company (call them Mr Smith) is very protective of its interface and sells their own very expensive software. We used a protocol analyzer and "deciphered" the protocol. Anyone with knowledge of general protocol structures could have done this just as quickly. Next we could have battled developing on the Basic module, but doing a little bit of research we figured it would be quicker and more cost effective to use a windows development environment and programmer (cheaper than control eng) to develop the code. Once this was done and tested (serial port) the code was ported into the Basic module - problem solved, happy customer, experience gained. I am sorry if I make it
sound simple, but it can be.

I have only just had a chance to read a clip from you to another lister and now understanding the number of I/O you are using (12 i/p, 12 o/p ?) then I would agree that the PC option would be
cheaper than a PLC. But then again if I was working with such a small amount of I/O I would have consider a micro-controller, - I'm sorry but I still believe in horses-for-courses.

One final thought, if the customer already owned some of this equipment, how did it communicate in the past? You earlier indicated that none of the pieces were able to communicate with each other. I do not condone the monopolies that vendors try to put on "their" part of the market. But I also do not condone monopolies being shifted from vendors to integrators. Please be clear that I am
not saying that you are doing this, but it does happen everywhere, even in sunny QLD, Australia.

Cheers
Allan Dow
Embedded Systems & Solutions

 

> ....I assure you
> that if you reckon your scope of options is limited then you should
> try my home ground which probably has only 1/20 the options offered
> in the US of A. Again I believe you are making the exercise of
> interfacing appear more difficult than it need be. For example, you
> indicated that you had to develop a protocol that would allow the
> devices to work together. Well thankyou for just introducing another
> protocol to the world - it is not as though we don't have enough to
> support. Why didn't you adapt - go to the web and download a simple
> already existing protocol more widely accepted one than yours (JBus
> for example). Now if your client wishes to add another device they
> will have to interface to your protocol, who is going to write the
> interface for them .

The only other protos for the robots were map and something that no one could provide information on. I would greatly prefer to use an existing proto. We did a BCD interface and documented it. I don't think using it would provide a challenge since it is all done in the user programs for the PLC and the robot which are customer property.

> Even reverse engineering is not really that difficult and done
> properly can offer additional benefits to the client. A quick
> example we had, a certain German engine company (call them Mr Smith)
> is very protective of its interface and sells their own very
> expensive software. We used a protocol analyzer and "deciphered" the
> protocol. Anyone with knowledge of general protocol structures could
> have done this just as quickly. Next we could have battled
> developing on the Basic module, but doing a little bit of research
> we figured it would be quicker and more cost effective to use a
> windows development environment and programmer (cheaper than control
> eng) to develop the code. Once this was done and tested (serial
> port) the code was ported into the Basic module - problem solved,
> happy customer, experience gained. I am sorry if I make it sound
> simple, but it can be.

It can be very simple or not :^), We shouldn't have to do it at all.

> I have only just had a chance to read a clip from you to another
> lister and now understanding the number of I/O you are using (12
> i/p, 12 o/p ?) then I would agree that the PC option would be
> cheaper than a PLC. But then again if I was working with such a
> small amount of I/O I would have consider a micro-controller, - I'm
> sorry but I still believe in horses-for-courses.

Come on now, the cost comparison gets more one sided as the IO count goes up. My point was that the hardware isn't the major cost of a PC system (unless you buy proprietary hardware) It's when
you add the big bucks for NT and the closed controls package. With the MIPS differential being what it is, we should be able to run more IO as well although distributing the process becomes more attractive at some point than a single monster PLC.

> One final thought, if the customer already owned some of this
> equipment, how did it communicate in the past?

They didn't, there were little pockets of automation and standalone machines. We are now integrating them. Pockets are relatively
straightforward, individual machines can use a single controller. It's when you have to make cells and integrate the cells that the closed
proprietary model becomes problematic unless you can start fresh with a single vendor.

 

>The only other protos for the robots were map and something that no
>one could provide information on. I would greatly prefer to use an
>existing proto. We did a BCD interface and documented it. I don't
>think using it would provide a challenge since it is all done in the
>user programs for the PLC and the robot which are customer property.

I appear to have lost the plot. I recall from earlier lists that you indicated you had to develop a protocol. Are you now implying that
the BCD interface and S/W that went with it is your developed protocol. If so then what did you do with the other 4 hours that day?

If not then you have done a cardinal sin according to your own ethos - you have release a new protocol to the world. Its a bit like a
vegetarian friend I have, she gets on her soapbox every chance she can denegrating us "...animal killing meat eaters". One day I asked her where she thought the rennet comes from that goes into her cheese (she loved cheese). When I explained it was a (by) product of animal slaughter it did not phase her, the excuse "yeh, but they did not kill the animal for the rennet, so why waste it". The point here is that we all use the "truth" and our beliefs to meet our own needs. By the way she still loves cheese and continues to jump on her soap box!!

>It can be very simple or not :^), We shouldn't have to do it at all.

I am thinking of developing a camera that I point at the process and it soughts out all the interfacing problems, writes the code, does the
commissioning and then prints all the documents and sign-off reports. The trouble is then I will have put people like us out of work and then I will have people from the "artificial intelligence" thread having a go at me for puttin them out of work What we are paid for is our
skills to get over problems and to troubleshoot (at least I am) - anyone can plug in a number of cards, be it PC or PLC. The skills are needed when they DON'T work. I am not suggesting for a
minute that the vendors problems do not cause a great deal of stress, but I think it is narrow minded to imply that one type of system is more prone to headaches than another, certain types in
certain environements fine - but cut the cr*p on the blanket statements.

>Come on now, the cost comparison gets more one sided as the IO
>count goes up. My point was that the hardware isn't the major cost of
>a PC system (unless you buy proprietary hardware) It's when you add
>the big bucks for NT and the closed controls package. With the MIPS
>differential being what it is, we should be able to run more IO as
>well although distributing the process becomes more attractive at
>some point than a single monster PLC.

I think we are talking chalk and cheese here on the type of projects we are dealing with. I deal with 15,000 point HMI packages and +1,000 point I/O systems that go into multi-million dollar
processes. I am still not convinced that a PC based system would suit this environment, but I would accept that PCs could be used in other control environments - again right tools for the right job.

>They didn't, there were little pockets of automation and standalone
>machines. We are now integrating them. Pockets are relatively
>straightforward, individual machines can use a single controller.
>It's when you have to make cells and integrate the cells that the
>closed proprietary model becomes problematic unless you can start
>fresh with a single vendor.

I have never disputed that "problems" do arise when interfacing products that may not have been meant to work together. Try putting a digital PABX phone on a PSTN line. It should work, after
all they are both phones. If you glue a piece of seasoned wood (old) to a piece of green (new) wood it wont take long before the craks appear. But it doesn't mean it can't be done, it just requires skill and experience.

Cheers
Allan Dow

 

You have indeed lost the plot. I didn't make a blanket statement. But let's consider yours " I think it is narrow minded to imply that one type of system is more prone to headaches than another". I can connect most of the PC's in the world together regardless of manufacturer fairly quickly and easily through an open protocol set.
I can't connect without great difficulty, three automation products that all profess communications capability, are products of the
same vendor, even though said vendor advertises "open".

Your inexplicable animosity on the subject aside, I think it is d*mned reasonable to consider that PC's as a class are less troublesome to interoperate than automation equipment as a
class and that the difference is deliberate and not in the best interest of the customer, or the system integrator, or anyone other than the vendor. Furthermore the technical explanations
of why 100 vendors require 150 protocols, all secret and none interoperable, could be used without change to argue away the internet, data networks, in general and the progress in
communications starting with the telephone.

The combination of commodity hardware and open protocols and OS's will obviously be easier to integrate and interoperate. Proprietary hardware and closed software are at least in part designed to prevent interoperability between vendors and to make it more difficult to use "foriegn" equipment . By the way I like your phone example. All analog phones are interoperable because the monopoly was broken up. The multitude of digital
standards were developed, at least in part, to regain control of the market for exactly the same reasons as proprietary "standards" in the automation world. Not only do you have to buy your phones from the PBX manufacturer, you need the PBX to interface them with the universal "open" standard. I am certain there was no greed or averice in this, it just happened.

cww

 

Dear Curt

I believe this thread is now achieving no benefit.

I will leave you with your conspiracy theory and screwdriver, if you will leave me with my cumbersome toolbox - to which I am happy to add a PC should the need ever arise.

Cheers
Allan Dow
Embedded Systems & Technology

 

I agree, but I'll leave you with this thought:
If "open" wasn't a desirable thing, all the big vendors wouldn't be advertising how "open" they suddenly are. And if they have no vested interest in controlling the market, it would be more than
advertising.

Regards

cww.

 

Exactly.

That is why when the SCADA vendor add COM interfaces to their systems I think of it as "open". Other people think I am on Bill's payroll. To me "open" means that I can easily use the piece of technology. Since COM and the other Microsoft OS mechanisms are the "standard" way of getting information to people then I am better off.

I use to think of "open" as things like OSI, POSIX, etc. But I was idealistic then and I thought that people made software to empower the people. Right on sisters and brothers!

 

You are insatiable, simplistic, and abrasive...Good thread!

 

Hi,

First of all I have to precise what is LabViewRT. This software used the standard G graphical language of LabView but the runtime is
implemented (dowloaded) to a PXI card (or in a near future to a FieldPoint embedded controller). So the remarks regarding the stability of a PC is not a criteria for your application.

Regarding the application you want to control, my opinion is that G language is more flexible than PLC languages. So for an application like yours I will recommend LabViewRT.

If you need more information, please feel free to contact me directly.

Steve Monnet
SAMPI2
www.smapi2.com
[email protected]