gm plant question

Chris:
We are converting, slowly, to using flowchart based software called Open Controls. The name is a lie though as there is nothing "open" about it. It is a difficult to understand system that people are avoiding like the plague. Do yourself a favor and stay with PLC's. They really do work better!

Ron Gage - Saginaw, MI
([email protected])

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
I work at Rockwell Software.
I thought it was interesting that GM was really the motivating factor behind AB developing the PLC in the first place, and now they appear to be
migrating away from that standard. We have a Soft PLC product called SoftLogix that is NT based. I always thought Linux would be a better platform for this kind of project. But it isn't supported around here.
Good luck!
Christopher.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Ohio.

There are people who are pushing for it.It even came up at a recent employee meeting with Rich Ryan. But at the moment and for the foreseable future the official stance is a definite no.

I am definitely a supporter. Most of the trouble RSI has with our stuff is related to obscure undocumented changes/bugs in MS stuff. Each service pack release is a nightmare! Having a fully open platform would be beautiful. Not so much for the ladder programming stuff, as for the SCADA type applications. Unfortunately I think it will be some time until we see Rockwell's position change on this. Then again I work primarily with RSLinx and RSSQL out of Ohio so things might be changing more quickly elsewhere.

Christopher

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Rob, This email just bounced several times from your personal email. hope its okay i sent it to the list.


----- Original Message -----
From: Christopher
To: Rob Martin
Sent: Wednesday, April 19, 2000 4:26 PM
Subject: your email.

If there is interest/development taking place they are not allowed to
discuss it. If you really think about it, why would AB be interested in
having you run Linux on an industrial computer? None of AB/RSIs software
runs on Linux so I don't understand why they would be interested in that. Don't get me wrong I think it would be great but I can see why they aren't jumping to try it.

We dislike copy protection and the inconvenience it places on us as well,
but we are a relatively small company (the software part is broken out of
Rockwell as a business and is a less than 200million dollar business) so a
small amount of pirated software would be catastrophic. We cannot absorb the
losses that MS can. (And in fact OSR1 one of MS Office MS will introduce a
key-based copy protection scheme similar to what we use) On the other hand I
haven't had any trouble with my keys (yes, internal software is protected
too) for over a year. I should also mention that each master disk can only be reset ten times before it stops working. (im only mentioning this to help you avoid the hassles associated with getting a new one.)

As for your com port woes, it sounds like you are using a pic. If this is
the case you deserve the trouble it gives you, go buy a pcmk card ;-)
Seriously though, I wish they would stop selling the pic. The pic driver is
very timing sensitive it cannot tolerate the timing interference placed on
it by the windows OS. (this driver/comm. system was designed for the direct
rs232 specs back in the dos days) and because NT doesn't allow direct access
to the com port (or any other hw for that matter) we must replace NTs com
port driver at boot time. There is no way to regain control of the comm.
port without stopping/deleting that driver and rebooting becuase this must
be done before the hardware application layer of NT can boot and take over
the comm port. If its a desktop use/install another com port. If its a
laptop i'd use another driver. As frustrating as you find this limitation imagine having to deal with it as much as I do.


chris

ps, after writing that i looked up the time you called into tech support. (You are with JAC right? ) they were right on the money really. there just isn't a better way to do it with rs232 to pic driver. your real beef about this issue isnt with RSI its with the way NT handles the comm port. (and its getting worse, laptop manufactureres are no longer adhering the the rs232 standard in an effort to decrease battery consumption...sometimes a pic doesn't work..at all on new laptop computers!)


----- Original Message -----
From: Rob Martin <[email protected]>
To: <[email protected]>
Sent: Wednesday, April 19, 2000 2:17 PM
Subject: Re: LinuxPLC: gm plant question


> from what i see in the milw area, there's little interest in pursuing
> anything linux. we volunteered to get it running on AB's industrial pc if
> they would simply loan us a unit to play with for a couple of weeks. three
> months later, no answer. and we're an AB large OEM.so what are we to do?
> move on to better companies with no regrets...like automation direct, which
> i gladly use regularly, and who provide us with source code for their
> product (let alone protocol specs) upon request.think AB would let me know
> how to program communication with a SLC over ethernet, even if i was in a
> position to drop $3k for a SLC 505 system? rumor has it, that's not
> available. i'll stick (when possible) with a D2-250 and H2-ECOM from A-D for <$750 with a rack.
>
> (actually, i have an application coming up that will require 505-to-Linux
> ethernet communications. i'm hoping someone in the LinuxPLC group will have
> done the hard stuff by then. i've also asked our distributor to bring in an
> SLC specialist to come argue with me.)
>
> <warning> i'm about to ask questions about rs's software that you might be
> able to answer. this really sucks of me to take advantage of you this way;
> perhaps you're a developer, and rs has tech support people to protect you
> from my ilk. feel free to stand sideways and tell me to rtfm or call someone
> in tech support.</warning>
>
> you work with rslinx!?! cool, can you tell me how to use it on my laptop and
> not lose (or at least be able to regain, on demand) my serial port? i called
> tech support and got totally unsatisfactory answers. i've had my A-B
> salesguy try to track down an answer -- he said I can't. (i like rslogix
> from a plc programmer's standpoint, but really despise rs stuff from a sys
> admin's perspective...rslinx and and the damn evmove disk are the biggest
> thorns in my side. typically i make rs give me new codes rather than dig my
> evdisk out...i think that rs deserves the cost of that call two or three
> times a year -- when i'm forced to program a SLC -- for trying to tie me down.)
>
> my personal opinion on the subject would require the use of offensive
> language, but suffice to say i install the software on demand only. twice
> i've had to reinstall winnt to get my serial port back (tho i may be at
> fault there since i'm generally too impatient to solve for the "correct" way
> of fixing problems with windows...not like linux where i search for answers
> diligently, try to protect my uptime, generally refusing to even consider a reboot.)
>
> well, that was fun. hope you don't mind my righteous indignation too much,
> or at least had the good sense not to read it.
>
> best regards,
> Rob Martin

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R
sorry i was unreachable a couple of hours; for some reason RH6.1 on my SparcStation 2 tries to delete the idle task once every couple of weeks. i find it frustrating, and the kernel outright panics. anyone know about this?

Pricing frustration: The RSLogix package costs a tremendous amount; significantly more than at least some if not most of the competition. If this price is driven by the fact that Rockwell Software was spun off into a separate entity and needs to make a profit, then I say too bad, so sad to them. I don't buy the software because I enjoy using it (or get any value out of it in and of itself); I buy the software to use the hardware, which is also terrifically overpriced. I cannot fathom what value they think I'm receiving by purchasing at these prices. But to spend $1100 on top just so that Rockwell Software can get their hand in my wallet next to Rockwell/Allen Bradley's hand is unreasonable. Then to deal with the loss of my serial port, and to deal with the EVMove utility is added insult.

Regarding piracy: Microsoft gave away Office in Korea when they wanted to run Hangeul Word Processor out of business. They sold Office for $99 with a "take it home too" license when WordPerfect ruled. Now they need $500 a pop plus copy protection? Likewise, RS's competition manages to sell better software at a lower price without the protection. I refuse to believe that they are running so close to the margin that they would be hurt by treating their customers like grown-ups.

Serial Port, PIC and PCMK: I realize you wish to blame NT for my serial port woes, since Microsoft is not allowing direct access to the serial port. However, I don't take issue with the hardware abstraction layer, and believe (though I could be mistaken) that this is at least partially responsible for the better stability I get from NT than 98. The PIC should be designed/improved/corrected to work under the prevalent operating system (or better yet, Linux!) You suggest that the PIC is crap, and I guess I can agree if it is to blame for my woes. But I'm not interested in losing one of my pcmcia ports either; nor am I interested in paying $1845 list plus software to communicate with an AB PLC. What right does any manufacturer have to say, "We're sorry, the product you bought is overpriced and doesn't actually work; buy this one that costs more than your whole computer instead -- it actually works."

Regarding the fact that RSLinx commandeers my serial port and refuses to give it back: why is it that no one at Allen Bradley seems to understand that they do not own my computer? Do they really think that by refusing to assist me in reclaiming my serial port resource, they can prevent me from programming the competitor's equipment? Hell, I can't even program an Allen Bradley servo controller when I don't have access to my serial port. I refuse to carry two laptops, one of which is dedicated to programming with RSLogix -- even though it'd be cheaper than buying the 1784-PCMK.

I went through the trouble of trying to recover that port once. I told RSLinx I wasn't using the PIC anymore. Reboot. No port. I found the PIC driver was still started up. Stopped and disabled it. Reboot. No port. I uninstalled RSLinx. Reboot. No port. How much am I supposed to suffer? Why will no one in technical support identify a procedure for re-enabling my serial port? It can be done, even if it takes a registry hack and uninstalling the software, right?

OK, so I've ranted long enough. My frustration at this "we're big enough to dictate your life" attitudes is the reason I love AutomationDirect. They avoid this b-s. They (Host Engineering) hand out source code on request. This is also why I'm involved in this group, even though I haven't had enough time on my hands to code yet. But you can be sure I want control over my computer and the software I run on it. I do not feel that Allen Bradley/Rockwell Software can be trusted to respect my money, my resources or my business.

I'm glad to say I have 100% free-as-in-speech software on my server at home, and Netscape 4.72 is the only exception on my workstation at home. Even with a kernel panic problem coming up three times in five weeks, I wouldn't go back to Microsoft if they paid me. Call me an open-source bigot ("Hi, Curt. Is it crowded under this label?") or whatever, but I am happier here.

Rob Martin

To Christopher:

Please feel free to forward my comments up the food chain at Rockwell, or let me know where to send them.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, 19 Apr 2000, you wrote:
>
> from what i see in the milw area, there's little interest in pursuing > >
anything linux. we volunteered to get it running on AB's industrial pc if > >
they would simply loan us a unit to play with for a couple of weeks. three > >
months later, no answer. and we're an AB large OEM.so what are we to do? > >
move on to better companies with no regrets...like automation direct, > which
> > i gladly use regularly, and who provide us with source code for their >
> product (let alone protocol specs) upon request.think AB would let me know >
> how to program communication with a SLC over ethernet, even if i was in a >
> position to drop $3k for a SLC 505 system? rumor has it, that's not > >
available.

First of all, might I suggest checking your mail editor, it didn't put in line feeds at the ends of the lines. Made things kinda hard to read. It also messed up the quoting as you can see below! :)

Second of all, might I suggest you check out the Allen Bradley Ethernet Library (ABEL). This is a Linux-centric library, available in source code form only, and it is VERY capable of reading/writing to/from a PLC5/xxE, a SLC5/05, or a Pyramid Integrator. Support for the PLC5 is best currently, as in it can read rung data, the force table, and the configuration tables directly. These features are lacking for the SLC5/05 and the PI but will eventually be added.
I am the author/maintainer of the project and am quite willing to assist people with integrating the library into their own projects.

The library may be downloaded through the following freshmeat link:

http://freshmeat.net/appindex/1999/11/07/941993013.html



i'll stick (when possible) with a D2-250 and H2-ECOM from A-D >
for > > <$750 with a rack. > > > > (actually, i have an application
coming up that will require 505-to-Linux > > ethernet communications. i'm
hoping someone in the LinuxPLC group will > have > > done the hard stuff by
then. i've also asked our distributor to bring in > an > > SLC specialist
to come argue with me.)

Any questions? :)

--
Ron Gage - Saginaw, MI
([email protected])

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R
Ron,

I knew you had done that work, and you can be sure I'll use it as soon as I have to connect an Allen Bradley SLC5/05 to Linux via ethernet. I'm
terrifically pleased you've done this work, because I know that my A-B distributor says he can't get me anything like it, and I did this once for AutomationDirect (alas for NT, not Linux) with their support. I did not want to do it for AB.

Thank you for letting me know again where to find it as well.

Regards,
Rob Martin

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Rob

I'm sure there's room under the penguin's wing ;^). This is the kind of thing that powers Open Source, "If you won't fix it, at least let me fix it myself". I was just gonna sit back in the weeds and smile. The explanation pisses you off as much as the policy. Well...back in the weeds, this HTML mail hurts my eyes.

regards
cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
I don't have time to reply to all of this right now.. but my point about the serial port is just this:

If we write to the windows api > rs232 > DH it wont work. Period. I am not trying to blame MS for our woes. You asked why this is the case and I am telling you.
When DH485 was designed there was no NT.
So the only solution is to take the comm port. Period.

There is no way to get around the timing issues in DH485, there is no wiggle room, no way to "improve" anything moving through the comm port.
We are trying to provide you with continued support. Microsft DOES NOT want that driver to be in RSLinx 2.2. and will not give us a Win2K approved sticker w/ it (or anything else that avoids HAL) Would you rather we simply gave up?
It is legacy equipment you are using. There is no way around that. Heck some new pc's don't even ship with rs232 ports.
In RSLinx 2.10.118 and later RSLinx can run as a service. If it is doing this it may grab your comm port, other wise after you reboot it should be returned to you. If it isn't you have some other problem, and you should talk to support. I am at home right now but from what I quickly glanced at while at work you only called in once for assistance with the pic driver and that was in 1998. Don't sell RSI tech support short.

I don't think this is accurate:
"We're sorry, the product you bought is overpriced and doesn't actually work; buy this one that costs more than your whole computer instead -- it actually works."

When did you buy the pic?
Are you still driving a car that uses lead gas? no? okay.. when they switched to unleaded were you on the phone with ford or chevy saying that they should replace your engine?

(I whole heartedly agree that the pic should not be sold these days..)

Also, if you were quoted $1845 for a PCMK then you probably alienated your distributor, which from the tone of your email seems likely.

If the tone of my previous email came across as anything other than helpful I apologize. It wasn't intended to.
I think you made up your mind about RSI a long time ago.

I am going to end this thread now. I joined this list to see what linux had going in the automation field because linux is a lot of fun. I honestly believe that although proprietary and for profit Rockwell has its customers best interests at heart when as they conduct business.

chris

ps:
you dont' really believe this do you? :
"Regarding the fact that RSLinx commandeers my serial port and refuses to give it back: why is it that no one at Allen Bradley seems to understand that they do not own my computer? Do they really think that by refusing to assist me in reclaiming my serial port resource, they can prevent me from programming the competitor's equipment? Hell, I can't even program an Allen Bradley servo controller when I don't have access to my serial port. I refuse to carry two laptops, one of which is dedicated to programming with RSLogix -- even though it'd be cheaper than buying the 1784-PCMK."
the sheer number of support calls such a tactic would generate would be staggering! There are thousands of Pics and pic drivers out there that happily release the comm port each and every time the computer is rebooted. I am telling you if yours isn't doing this you have some problem and tech support shoudl be contacted.




Serial Port, PIC and PCMK: I realize you wish to blame NT for my serial port woes, since Microsoft is not allowing direct access to the serial port. However, I don't take issue with the hardware abstraction layer, and believe (though I could be mistaken) that this is at least partially responsible for the better stability I get from NT than 98. The PIC should be designed/improved/corrected to work under the prevalent operating system (or better yet, Linux!) You suggest that the PIC is crap, and I guess I can agree if it is to blame for my woes. But I'm not interested in losing one of my pcmcia ports either; nor am I interested in paying $1845 list plus software to communicate with an AB PLC. What right does any manufacturer have to say, "We're sorry, the product you bought is overpriced and doesn't actually work; buy this one that costs more than your whole computer instead -- it actually works."

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R
Christopher,

For me, this thread has gone on for three years, since I purchased RSLogix. I assure you that what I've written was said in complete sincerity and good faith. I am now very much a Linux and Open Source bigot, but when these problems began, I was equally an advocate for Windows NT.

I have spoken to RSI tech support on at least four or five ocassions and complained about my inability to reclaim my serial port on at least
three. The last time I called was in the end of January or beginning of February. I very specifically explained my problem -- the serial port would not work under other applications -- and asked for his assistance in solving the problem. He told me in no uncertain terms he did not know if an uninstall would get me the serial port back, did not know how to get it back, explained that the software required the permanent use of the port, and he did not know, short of reinstalling WindowsNT, what would get me the port back. I reinstalled WindowsNT. I immediately called my distributor and raised cain. He tried to track down an answer and told me it could not be done. Forgive me for my indignation, but this is what I've been told. Repeatedly.

You say that what I wish to accomplish can be done. I will look at the version number tomorrow and compare the version you described against
the release I purchased in late '97. Meanwhile I have a voice mail on my distributor's voice mail requesting a meeting with a technical
representative of AB or RSI to come to my facility to discuss this problem. I anticipate that this will happen soon. Our distributor is
great, and he works his butt off for me. I wouldn't dream of changing. My beef is with AB and RSI. Until she left AB for Waukesha Engine, our factory rep was Erika Guzman, who was also dedicated to service and never once disappointed me.

You say that DH485 will not work across a HAL-protected serial port. I suggest that the PIC should communicate via RS-232 to the host and DH485 (which I, perhaps erroneously, see as a perversion of RS485 designed to obfuscate and make proprietary a standard method for communication) to the PLC. When the majority of other PLC's manage to offer a variety of
standards-based communications, I take issue with the fact that AB offers no method of communication from within RSLinx that is not
proprietary.

As a disclaimer, I have not looked into other methods in two years, since my frustration began. I changed vendors and avoided working with
AB whenever possible. As a contract design and manufacturing shop, I cannot always do that, and I also support a variety of customer-equipment in the field designed around SLC hardware. However, I
will continue to assume that my statement regarding standards is true, since you have suggested the best alternative is to purchase a
1784-PCMK. Also, although I quoted list price for effect (as quoted by the distributor) I know that my cost is less -- $1215.86, which I find
equally horrendous for <$50 worth of components.

If the PIC is deprecated then AB should perhaps update it (I do not think it is too much to ask for standards-based communications), or obsolete it. However, in looking at my price bulletin this afternoon, I was unable to find the 1784-PCMK at all, whereas the PIC appeared in three places I identified.

I am not selling RSI tech support short. I am reporting what I was told from several channels. My number at work is 262-495-2141. I'll be in by
10:00 AM EST Thursday and will gladly discuss this with a tech support person who is willing to walk me through an install that will allow me
use of my serial port -- even with rebooting since it appears necessary -- that does not require me to give up a serial port permanently.

I apologize that you caught the tail end of several years of frustration regarding this problem. I honestly feel that RSI has been more than unhelpful -- I feel that they have stacked the deck against my ability to program other devices. I have not alienated my distributor; I work closely with them on many product lines and we represent one of their key accounts. I did take your email as "toeing the company line", and I apologize if that is mistaken. Apparently you have a different view of the problem than I, and I would like to see your view work successfully
in my application. I understand and do not begrudge Rockwell's interest in profit. In a sad way, I can even appreciate the high price. If my
customer insists on AB, I mark it up the same percentage as I do the inexpensive alternatives. But I don't specify AB on my designs because I
cannot justify the price/performance ratio. I do disapprove of the insistence on proprietary communication technologies. When they add value, I am happy to choose proprietary technologies. (For me, this is the case with Automation Direct.) But I prefer to have a choice.

When I started this thread I honestly felt that RSI had given me a standard end-run designed to prevent users from working with other systems -- similar, in fact to the Microsoft method of working well within the family, and playing poorly with competitive software. I had hoped that an Linux advocate at RSI might be able to say something along the lines of, "I shouldn't be telling you this, but if you edit the following registry key, the standard driver will take the serial port back..." I even encouraged you to bump my request right back to tech support so as to avoid an uncomfortable situation.

Now I encourage you to continue the thread and address the other concerns I listed earlier. I apologize that my longtime experience with this has predisposed me to be cynical and negative. I will make a sincere effort to understand and appreciate the position you demonstrate
without a negative bias.

Regards,
Rob Martin

--
M. Robert Martin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Q: What is the square root of 4B^2?
A: "To be, or not to be..."

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> (which I, perhaps erroneously, see as a perversion of RS485 designed to
> obfuscate and make proprietary a standard method for communication) to
> the PLC. When the majority of other PLC's manage to offer a variety of
> standards-based communications, I take issue with the fact that AB
> offers no method of communication from within RSLinx that is not
> proprietary.

The biggest problem is that DH485 requires very tight timing in the messages. There is absolutely no tolerance in the protocol for "late responses". If a message can't make it in the appropriate time slot, then the message is
ignored. Often times from that, the PLC will drop the connection to the PC. This even happens (a lot) with older SLC's and a PIC under Win9x. The data stream can't tolerate the (operating system generated) randomness of the response timing. AB has to do "tricks" like write a driver that takes the serial port away from the HAL to guarentee the timing issues are at least
partially solved. As you have obviously discovered, this leads to other problems.

Oh, and DH485 is actually closer in spec to RS-423, 4-wire multidrop communications. :)


> If the PIC is deprecated then AB should perhaps update it (I do not
> think it is too much to ask for standards-based communications), or
> obsolete it. However, in looking at my price bulletin this afternoon, I
> was unable to find the 1784-PCMK at all, whereas the PIC appeared in
> three places I identified.

To update the PIC to solve the problems would require adding a CPU and RAM to it (so it could buffer the data stream from the PC and therefore deal with the tight timing issues by itself). Given AB's penchant for marking stuff like this up, expect something like this to cost in the neighborhood of $1200. Now you are at the price point of a PCMK, hense the "why bother" attitude.


--
Ron Gage - Saginaw, MI
([email protected])

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Thanks Ron, well put!
thats all im saying..
and NO you CANNOT code around it. not if you want to use the dh485 spec. there is no hidden registry key, why would we want to hide that?
We don't care/mind if you use other companys devices.. go to our website and look at all the data servers we advertise for connectivity to other companies devices. Look at www.opcfoundation.org we are a major player in
that open standard.

As more and more people require data gathering and logging instead of "just" control, the bandwith limitations of legacy DH485 networks will cause them to be fazed out making this a non issue anyhow.

There is no vast conspiricy in the automation world trying to keep you from using whatever you want Rob. The idea that we are secretly trying to keep your serial port from you is just silly.

I didn't join this list to do tech support, I just thought linux and automation together made sense, and would be interesting. I don't mind
helping with that aspect of it. If you need support with RSI software go through the proper channels.

Rob unless you switched companies you've called in 12 times. 2 times were in reference to the pic. Both of these were in 1998. A lot has changed since then.

chris

ps, if this comes accross formatted badly someone let me know. I have several computers I have written to this list on, so I dont' know which is
sending poorly formatted messages.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Jack Gallagher

Christopher,

I have to agree with Rob on this one. You cannot say that Rockwell has their customers best interest at heart if they are willing to sell software and hardware that does not work, then tell them after the sale that "ohh, by the way, Windows is the problem, not our software".

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J
Maybe it is just me, but this seems WAY off topic. I have had my share of heartache with AB/RSI as well, but I doubt that Chris is to blame for it all. If you don't like it, don't buy it. AB is not the cheapest, it isn't the best, it just has the largest installed base (sound like an OS we all know?).

In the mean time, let's cut Chris some slack. If he had the power to change it, it sounds like he probably would. I can speak from my time inside AB, however, that anything said by someone inside concerning product improvements is summarily ignored by the members of management. That's why I left.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
I was only kidding when I said go buy a pcmk. The pic can and does work the majority of the time. It is not ideal, as it was never initially designed for NT. The ideal best solution is a pcmk.

Rockwell has their customers best interest at heart because we bend over backwards trying to support legacy hardware that was never designed for todays operating systems. If they didn't still sell the pic then people would complain that "they only stopped selling it to force people into using the expensive pcmk"
I do wish the sales force would set more realistic expectations for the pic.

The "can't get my comm port back" isn't typical. I have two desktops and one laptop computer that work fine with a pic, I do have to reboot to regain the use of my comm port. Windows IS the reason I have to reboot I don't know why this is so hard to believe.

chris

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
> I am definitely a supporter. Most of the trouble RSI has with our stuff is
> related to obscure undocumented changes/bugs in MS stuff. Each
> service pack
> release is a nightmare!

You should try to install WinCC on Windows 2000, you get a nice little message saying that this software requires Service Pack 4, that only Service Pack 1 is installed (already?) and that the installation will abort.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top