Dear Dave,
I’d like to discuss an adjustment to the contract to compensate for problems caused by actions of, and added tasks resulting from decisions made by USACE personnel. These things have hampered progress and added tasks to my critical path.
It seems fair that some of the wasted time and money caused by people actively working against this; along with the added expenses resulting from Ed Miska’s decision to switch from RS-232 to OPC communication be restored. You and I agreed to this major change to the system design because we have a time and material contract.
In his letter of April 13th, Ed is speaking as if this were a firm fixed price contract, a misunderstanding that has been made before.
During contract negotiation, due to the difficulty in defining the system design and scope of the project, you and I negotiated to a “time and material” contract to allow future adjustments for unforeseen problems and provide latitude for design changes - such as the switch from RS-232 to OPC communication first suggested by Dan Perrier in Sept ’04, and later mandated by Ed Miska when he returned from leave.
Please recall that I had initially planned to use the RS-232 port in my proposals during contract negotiations with you. A cheap, easy solution that was changed at Ed’s direction to the more expensive OPC technique, that we all went along with it because it was a time and material contract and everything was going to work out.
This change was initially thought to be trivial, but adopting OPC technology turned out to be long and expensive, fraught with many pitfalls and ugly surprises.
It was easy to switch from the $125 RS-232 board to the $925 RSLinx OEM server because it was a time and material contract; easy to add the $2,500 RSLinx SKD server (which I had to buy when Ed couldn’t provide the VB docs from HDC’s copy of RSLinx SDK) for the same reason.
It was unfortunate that it took so much time to learn that Rockwell doesn’t support their software, and then to compile enough documentation that they don’t to persuade Ed to allow use of something other than Rockwell RSLinx brand servers.
After I agreed to buy the RSLinx SDK as a project expense, you commended Ed for his skilled negotiation in persuading me to buy this $2,500 software on the project, but after I reminded you this was time and material, you agreed it was moot – or nearly so. We agreed that whatever the consequence of this change, we’d worry about it later.
Now we know the consequence was an unplanned $3,400 for Rockwell software, another unplanned $2,390 for Software Toolbox software, an unplanned $1,000 to ACSI, and the unplanned 5 months from December 17, 2004 until now that it has taken to get the OPC connection working correctly. (Not only working correctly, but also to work with it enough that I’m comfortable fielding it as a product of mine. There’s more to this than slap-dash, get it working and out the door. It takes time to get it right.)
By my 25 years experience at this, rushing a product out the door before it’s ready is a guarantee of failure. A year from now no one will remember we did a favor by shipping 2 weeks earlier, they’ll just remember we shipped an item that could have used another 2 weeks of work on it.
To be fair, I believe the arbitrary 1 year and $160k limits should be adjusted to give back the lost time and added expense resulting from these added problems and tasks; and they can be because we have a time and material contract. I estimated and quoted this project assuming a cooperative, helpful environment, with everyone pulling in the same direction, but this has not been the case.
Before making this decision, a test/demonstration of where I’m at with the hardware/software for the ITB is in order, but let’s be cognizant of where we are in the progression of milestones, and see how much has been achieved so far (and what obstacles have been overcome).
Let’s take stock of where we are.
At the onset, I had no idea how prodigious and difficult these two tasks, neither of which was in the contract, would be. Now that they are done I’m glad for the education, but they’ve burned up a lot of time and money. We now have all the pieces for the prototype Data Collection Unit everyone wants. The OPC connection was the last piece.
The test/demonstration I’m setting up now will just be a demonstration of the Test Unit for the VB ActiveX OPC Data Control technique, not the delivery of a finished product. The finished product will evolve over time as software upgrades are made to flesh out all of the features described in the contract. This demonstration will just be data collection.
Since the first of the year, I’ve been reluctant to put forth a plan because I didn’t know how long it was going to take to get an OPC communication system compatible with the current GDACS system working, and do it within my skill set.
I couldn’t know how long the schooling (self-taught) on OPC and finding a vendor with a method compatible with Visual Basic and within my skill set was going to take. It took so long I had to make voluntary concession in my invoicing to ease my conscience.
I’m glad to report that I’ve found the solution to all of this in Software Toolbox. With their products, assistance, and ACSI’s working model of a GDACS OPC connection, I’ve got the OPC communication part of this working well and ready for test.
We’re putting together the plan now to get it to HDC for inspection.
To make sure it gets there and setup OK (and to make it easy on everyone), instead of just shipping it out and someone at HDC needing to reassemble it, my assistant will hand-carry and setup the complete ITB bench test rig I’m using here now.
The ITB (Tower desktop PC, monitor, keyboard & mouse), LinkSys Ethernet switch, SoftPLC, PanelMate display and all necessary cables will be provided; the test rig will be packed up here, and then unpacked and setup there, and be working before he leaves.
At the same time I’ll return the SoftPLC, PanelMate and TopDoc program to HDC, and turn over the two RSLinx servers purchased for the project.
(Late note: HDC refused to pay for the servers, so at the end of the project workscope, I harangued Rockwell about their falsely advertised support for this equipment and how much havoc it caused. With Dave Ebner’s assistance I got a refund from Rockwell and returned it to the project funds - effectively giving the refund back to the Government.
Ed indicated he’d need to coordinate with other USACE departments to get the virus scanning and other GDACS compatibility testing done. My assistant can stay a few days to a couple weeks to assist with this if you desire, and will return whenever needed to facilitate this further.
(Late note: We learned after the project was completed
that the virus scanning consisted of running Norton anti-virus on the ITB
executable programs that were received from ATECo – a 5-minutes procedure. Ed
insisted on 3-days for scanning, and by the time that the last version of the
software was sent to HDC, this had been increased to 5-days. Each of these
waiting intervals for “anti virus scanning” delayed project progress and added
to the total time required for the project)
The coordination Ed is doing is more than scanning this one computer and its software one-time. What is needed is a procedure for anti-virus checking of continuing software updates. This would allow program changes to be made here, emailed to HDC for scanning, and then on to McNary for installation in the ITB.
Last September in a meeting with Lee Sheldon and/at ACSI to discuss the OPC connection technique and get some information about it, I found that they were not very forthcoming with useful information, instead Dan Perrier was trying to get a P.O. for ACSI to do this programming work for me.
I did end up buying the technique from ACSI, much to my chagrin. After working directly with them, now I understand why some people say what they say about them.
When I was at HDC in September, Rod Wittinger told me not to get involved with ACSI. At that time Rod was my Task Master in this so I avoided them.
When we spoke last month about this, Rod agreed that biting the bullet and buying the interfacing information from ACSI seemed the best resort, but he told me to be careful.
As it turned out, I got the full measure of my RFQ and PO from ACSI without an overrun - but they did try to make one.
Doug.
Comments on E’s letter:
In his letter of last week, Ed Miska says “There is a significant danger of running out of funding…” We need to discuss this; we’re working with a time and material contract.
He goes on to say changing to Windows XP Home is no problem, but I must disagree.
Two IBM PC’s were purchased with Windows XP Pro for the ITB project; the Windows XP Home is in my Dell laptop. Swapping that out and delivering a different system from what the contract describes could be construed as fraud. Even if done only temporarily, there is still the danger of misunderstanding if a partial or substitute system is delivered.
At this time, I don’t think I’ll need any more from ACSI. The OPC interface to GDACS is working in the ITB desktop PC.
As for Ed’s side note, I’d like some clarification here. The contract says I’m building a prototype for the final system, and I’m going to be delivering up to 320 of them.
Ed is telling me not to bother to put forth my best effort on this because he’s going to do it over again, later (& better), after I show him how to do it. Maybe it’s my thin skin, but this offends me.
His statement that my VB code will be discarded so I need not do my best work, and to rush whatever I have into the test because we’re running out of time forgets the “time and material” nature of the contract, and ignores the delays and expense caused by covert interference and the RS-232 to OPC change that he added.
I would mention that the source code for the statistical analysis in the SteadyState routine of the program, written before the contract was signed, is protected by Copyright. Source code for this part will not be given over; only the resulting executable DLL* will be.
* (a DLL is a Dynamic Linkable Library. This is a collection of software algorithms that can so a specific task, but does not have the full capability to execute alone in a computer. DLL’s must be linked to other software programs that have this capability to be useful.)
(Late note – the HDC Response document complains that
this executable DLL was never produced; with good reason. Firstly, any DLL or
other partial programming was never to be widely distributable or independently
usable by the Government. Each DLL would have been hard-coded with the serial
number of the PC, hard-drive and National Instruments I/O board to prevent
using it in any PC other than the one I had keyed it to. Dave Ebner agreed to
this in theory, because the contract specified the software was to be
individually purchased as indicated by the line item LI0003 on page xxxx of the
contract. Allowing key elements of the ITB Copyrighted programming to be widely
distributed by the government defeated the price schedule of LI0001 in the
contract.
Secondly, when I attempted to produce this DLL, it was
learned that programming a DLL was going to require some additional study as to
the methodology, and extensive software testing to make sure that it would work
properly, and the Government was not going to pay for these efforts.
Dave agreed that because the DLL’s would not be widely distributable (or copyable) by the Government, and there was danger of future difficulties with setting a DLL up for use by the Government, that I could forego creating DLLs and continue working with the “whole-program” executable method that I had been using successfully all along.)
I’d like to point out that all along, USACE internal politics have caused much wasted time; equipment was promised for my use and then later denied, or as in the case of the 3-D Cam MockUp, it was missing altogether when I called for it. Later, after it was found at ACSI, disassembled and scattered about the back storeroom, I was still unable to get any components from it to facilitate my testing. These components were obsolete from the vendor [MTL] so I could not get new ones either.
For some time, it seemed that each time I would put forth a plan; the situation dictated from HDC there would change to prevent it. The “stand-alone 3-D Cam” on Unit 5 at McNary was supposed to be available for the ITB while we were negotiation on the contract. Inspecting it was to be a main goal of our trip to McNary.
Shortly after the contract was signed and we set about getting a look at it, we learned that the 3-D Cam was gone, replaced with its obsolete predecessor, the Seawell 3-D Cam in its place. The Seawell was altogether unsuitable for our use.
During our visit to McNary, Rod Wittinger got assurances that the stand alone 3-D cam would be made available for this, but later when I tried to get information about it, we learned it had been made unavailable again. My letter to Dave Ebener of 10-12-2004 detailing these and other problems prompted your Stop-Work order and internal wrangling that set things right.
The resume work order on 10-25-2004 put me back to work, but
did nothing to make up the lost time and money that internal USACE problems had
caused.
Listing
of specific delaying tactics
25
May 2004 project start
First
delay was due to insurance problems.
It
took 3-weeks to figure out that the insurance agents in Illinois didn’t
understand the requirements. Dan Perrier hooked me up with his insurance
carrier, who got me fixed up.
Once
I got the insurance in force, waited for Lee to return from Texas on 6-30-2004.
Ordered
IBM computers originally the day after contract signing.
The
computers were backordered by IBM, and then IBM canceled my order so they could
get out of the sale price I got on the computers. Reordered 6-21-2004, received
them 7-14-2002
July
8, waiting for decision from GDACS Committee on connection method.
Prior
to going to Portland at the end of August, I tried to learn enough to get
started on the design phase. Misinformation, disinformation and no information
at all from people caused problems from the start. Started working on bench test demonstration
hardware. I hadn’t seen the mockup at HDC, but from discussions I had a good
idea of what it is. Learned later that it was missing altogether. Was found in
the back storeroom at ACSI, disassembled and scattered about the room. MK was
assigned to reassemble and make it useable for a bench-test of the ITB. This
never happened.
Worked
on communication interfacing and computer virus susceptibility issues. Slow
going, but progress was made.
July
16 2004, SoftPLC about virus susceptibility, Cindy Hollenbeck says talk to Dan
Perrier about communicating with SoftPLC. Rod Wittinger had instructed me to
stay away from ACSI, so I did.
August
22 to 28, 2004 Trip to Portland. While I was in Portland, it was decided we
would use the stand-alone 3-D cam and I was going to modify the code in it, so
HDC ordered a TopDoc program for me to use. It didn’t get ordered right away.
On
September 2nd, Cindy Hollenbeck, the normal person in sales at
SoftPLC was in Seattle training USACE people on their system. It would have
been helpful for me to attend this training session. It would have
speeded up the project considerably had this training been made available to
me.
I
spoke with their Bookkeeper, Lisa, who said the P.O. for my TOPDOC program
hasn't come through to them yet.
Sept 7, Ed Miska on board
Sept 9, draft of ACSI Task order to help out
Sept 13, I still want the TopDoc program. I pushed for a Task Order to ACSI to get their assistance to get the interface working.
Sept 15 MTL Listening post drops discussion.
Sept 21, TopDoc finally ordered, learned there would be no stand alone 3-D cam. MTL has a Listener card for I/O. We could tap into the sensor side of the SoftPLC. One-way fiber-optic?
Sept 22, spoke with Cindy at SoftPLC about dongle and manual. Setting up Panel Mate, shopping for RSLinx OEM. Ed suggests using RSLinx OEM to spoof the 3-D cam into thinking it’s running a turbine.
Sept 24, purchase RSLinx OEM.
Sept 27 looking at tapping into serial communication between SoftPLC and Panelmate. Sent receipt to Ed for TopDoc
October 3, received TopDoc program from HDC. I had asked for this to be “drop-shipped” to me here. But it went to HDC anyway. It was sent to me after preparing a hand receipt. I worked on other areas of the project during this time, but the main thrust was supposed to be getting the SoftPLC communication working.
October 6 Top doc finally working. Problem was with dongle software; Cindy had told me to plug in the dongle, and then load the software. This causes Windows plug-n-play to assign unknown device driver. SoftPLC’s dongle driver doesn’t displace the dummy driver from windows if software loaded after dongle plugged in, so the dongle software would not load.
It was troubling that when I first contacted SoftPLC, I was instructed to install the dongle first, then the software. When this didn’t work, after a few other things that didn’t work, Cindy suggested I call Dan Perrier for help. After some wrangling, she agreed that wasn’t such a good idea.
I spoke next to Lee Parmeter. We ended up talking to the company that SoftPLC buys the dongles from; tracking the problem down to the dongle driver; going into the RegEdit program in windows and removing the dummy driver from Plug-n-play. For some reason, the Windows Device Manager wouldn’t do this. This wasted 2 weeks.
All this time, we’ve been looking at one-way communication methods that would not allow writing back into the GDACS. ACSI was recommending OPC communication, but this was not allowed due to virus infection fears. We made some progress on the hardware and software, but the main thrust of the project was thwarted by our inability to connect to GDACS.
When this project was started, I just wanted to use the
RS-232 port on the SoftPLC to make the communication. Clay Fouts told us that
all of the ports were all being used. Then we found that was not really true;
there were open slots in the SoftPLC, another RS-232 board with 2 ports cost
only $125, and the CommGene program was free. Seemed the cheap
and dirty solution everyone wanted, but no. Instead, Dan Perrier suggested, and
Ed Miska specified OPC communication using Rockwell RSLinx
After spinning my wheels chasing after a moving target of
stand alone, or no stand alone, 3-D cam, or GDACS…, I wrote a letter to Ebner
describing the problems.
======================================================
Doug Albright
Actuation Test Equipment Company
3393 Eddie Road
Winnebago, IL 61088
815.335.1143
October 12, 2004
David Ebner, A & E Contracts
Army Corps of Engineers, Portland
503.808.4611
Subject: Contracting Officer’s determination of technical direction
Re: Contract W9217N-04-D-0009
Dear Dave,
We’re still stumped by the same problem, four months into this project. The prohibition from connecting my equipment to the GDACS system still prevents the interface specified in the contract.
On Sept 2nd I send an Email asking for some direction, and the response was that a stand-alone 3-D cam would be provided by Mid-October for this project. In mid-September we were informed this was delayed until mid-December, and then at the end of September we were told there wasn’t going to be any 3-D cam; but no name was given as to who made this decision.
This is a resubmission of a request for technical direction from USACE as to how I’m supposed to get these signals from the GDACS system.
The following is an overview of where we’ve been with this, and a proposal that I believe will make it through all of the wickets that have been identified:
Glossary
A brief history
Two weeks into this project, Rod Wittinger realized from the pictures taken by Ryan Sollars at McNary dam that a Seawell 3-D cam was installed on Unit #5 instead of the NWP 3-D cam developed by USACE.
The availability of the NWP 3-D cam was a precondition of the contract terms stipulating the head, tail, gate and blade signals from the unit would be provided to the Index Test Box by USACE.
When this problem became known, you wrote telling me to hold off on conversations with ACSI and the GDACS committee until internal conversations at USACE resolved the conflict.
A short while later I was told that a stand-alone NWP 3-D cam would be installed “in two weeks,” providing the necessary interface for the Index Test Box demonstration. If all had gone according to this plan, an NWP stand-alone 3-D cam would have been on the unit when I came out there in August. However, when I arrived at McNary, this installation had not been done; the Seawell cam was still on the unit.
As I was preparing to return home on August 27, I was told a NWP 3-D cam would be put on Unit #5 “by mid October,” providing the necessary interface to meet the contract requirement.
In mid September I was told the plan had changed, and that a NWPR 3-D cam (GDACS + 3-D cam version) would be installed on Unit #5 for now, and that a stand-alone NWP 3-D cam would be installed by mid-December to provide the necessary interface to demonstrate the Index Test Box.
Last week, Ed Miska and Lee Sheldon both told me there had been another change, no 3-D cam would be provided as previously stated. Neither Ed nor Lee knew who had made this decision that effectively blocks any testing of this new equipment.
At every turn, the need for dedicated funding before providing assistance has been restated. There is no money allocated to pay for development and deployment of the stand alone NWP 3-D cam or modified GDACS + 3-D cam needed to facilitate this project’s tests and avoid direct connection to GDACS.
With all that has happened to date, I have diminished confidence that a stand-alone NWP variant of the 3-D cam will ever be made available for this project - and even if it does become available, it will not satisfy the contractual goal of multiple connectivity to GDACS equipped units.
Possible Methods that
could be used
1. As in the
original proposal, ATE Co would provide all of the pressure transducers, making
the Index Test Box completely independent of the powerhouse instrumentation. This was changed during contract
negotiations by USACE to use normal powerhouse signals from the GDACS system,
except for the Winter Kennedy pressure, which in any case will be supplied with
the Index Test Box.
2. Install
another RS-232 board in the SoftPLC and modify the GDACS program to send Head,
Tail, Gate and Blade values to the Index Test Box. The Index Test Box would
send new blade position values to the GDACS 3-D cam over the RS-232 port. Dan
Perrier said he didn’t want to modify the GDACS software to output data to the
Index Test Box. His preference was to:
3. Use the
RSLinx SDK software to communicate directly with the stand-alone 3-D cam
SoftPLC using the OPC technique. After
conferring with Ed Miska, I purchased the RSLinx OEM version of this software
to communicate OPC with the SoftPLC in the stand-alone 3-D cam configuration.
Just after the software arrived here, we were told there isn’t going to be a
stand-alone 3-D cam. This method won’t work because the GDACS Committee won’t
allow the direct communication with the GDACS computer.
Note: The proposed stand-alone NWP 3-D cam would facilitate a one-time demonstration of the Index Test Box, but will not satisfy the contractual requirement for a GDACS compatible index testing system that could be used throughout the system.
4. While at McNary, we discussed another proposal. The Index Test Box could monitor the normal RS-232 interface between the GDACS SoftPLC computer and the PanelMate display and get all of the necessary information without affecting normal unit operation. This method still connects to the GDACS input, and could conceivably inject a virus into the system. Additionally, this bi-directional monitor on the normal communication to the front panel display has been discouraged by ACSI, who recommend an OPC communication system to the SoftPLC, which again, is precluded by the GDACS prohibition.
And my current favorite:
5. IMC Company makes the Ethernet to fiber optic converters currently used with the GDACS System. They also make a unidirectional version of this device that would assure one-way communication from GDACS to the Index Test Box to prevent writing any virus back into the GDACS SoftPLC.
For this first demonstration project, the unidirectional transmit board could be daisy chained into the GDACS SoftPLC. This would not require any modification to the GDACS software, and would be completely transparent to normal GDACS operation.
To get blade position control by the Index Test Box, the Index Test Box would have the 3-D cam function built into it, and be programmed to drive the Indexer for the stepping motor on the mechanical 2-D cam directly. This would bypass the GDACS 3-D cam function and avoid any communication to the GDACS that might infect it with a virus.
Note: Another benefit of this method is the credibility of the IMC unidirectional communication system. This system was developed for some unnamed military group for a project that could not be discussed, in numbers they could not specify. If it’s good enough to protect a secret military project with unidirectional communication, it should work for us here.
Once the unidirectional communication method is demonstrated, costs of this method could be reduced by removing the two Ethernet/fiber optic media converters and just connect the Index Test Box input to the Ethernet output pin on the GDACS SoftPLC. If the receive pin on the GDACS SoftPLC isn’t connected to anything, there’s no way any Virus could be written back into it.
This method would also work with the RS-232 port, but this would require some modification of the GDACS SoftPLC software program to implement the output data stream.
Lee Sheldon informs me that the HOT committee is meeting on the 28th. This might be a good time to present this (or some other) proposal for comment and implementation.
Best regards,
Doug Albright
Thurs Oct 14 2004,
Mr. Albright,
You are hereby instructed to STOP all
WORK immediately and in any way related to this Task Order. You will be given a Notice to Proceed once
the Project Delivery Team determines when and how to get you access to the data
feed you need for the ITB.
Also, please be careful who you talk
to. Only the Contracting Officer and his
authorized representative(s) can make any change to the contract. Right now the CO is Ralph Banse-Fay, the
Contract Specialist is me - David Ebner, COR is Wayne Todd.
Talking to outside parties often creates
misinformation within the community of those involved. Right now I am told we cannot put the correct
3D Cam on Unit 5 at MCN and no one knows who said no, or why! Follow?
It supports the problem of too many chiefs and not enough Indians. No slur intended. You follow?
Talk to Lee and Rod and Wayne. Only, please.
October 25, 2004 Return to work
Oct
26 resume work, OK to use GDACS, need instruction on TopDoc program. The plan
at this point was for Ed to get a TopDoc program, SoftPLC and VB6 compiler to
work along with me. He would be able to get with ACSI to get basic operating
instructions for SoftPLC, TopDOC, RSLinx and help me get a head start on this.
He would have a VB-6 compiler so I could send stuff I write to him so we could work
on this together. This plan didn’t happen. Ed got busy with something else.
Nov
10, Mockup was being repaired, and I was supposed to be able to borrow some MTL
I/O modules to spoof the SoftPLC with simulation signals.
Ed
will take care of SoftPLC/GDACS mods.
Nov
17, start of discussion of auto flush. No help from ACSI.
Nov
22. Question GDACS/3-D cam on Unit 5.
Nov
24 bought transducers.
Dec
1. No mockup. No MTL I/O modules.
On December 10, Ed wrote a letter very critical of my looking for the C code in the SoftPLC after he told me not to spend any more time on it. At this point I was doing this on my time, not yours. My curiosity to see the C code was piqued to find out whether or not the C code was actually ever in the SoftPLC. If it was not, then why was I given the TopDoc program by HDC (Rod ordered it on your credit card) and directed to get into the C code to edit it for the stand-alone version of the 3-D cam, when it was never there in the first place?
The time spent figuring out the problems with installing the TopDoc program, untangling the driver for it’s security dongle, and figuring out how use the program had no useful purpose to me. It was a wasted effort from the onset because the C code I was looking for was never there in the first place. When I complained of this to Ralph Banse Fay, he excused Ed for not knowing there was no executable code. This is a fundamental, basic programming concept in the GDACS, if Ed truly didn’t know, then why is he in charge?
Why was I ever directed to work with C-code in SoftPLC? 4-weeks wasted.
December 16, 2004, learned the Rockwell SDK programming tool was unavailable from GMT. Ed had promised to loan this to me, so I needed to buy my own. Ed says to stay with very cheap and incidental, which would have been the RS-232, instead of OPC method, but the SDK program was $2,500.
12-17
Ed says not to build the flushing system. Another draft of Task Order to ACSI.
Ed absolutely insists I use RSLinx
============================================
Doug,
We have discussed this dead end before. Do NOT go
there. You need the RSLinx software.
If we later integrate the function into GDACS we may not need any
extra RSLinx software products.
Regards, Ed
In a message dated 12/17/04 11:42:49 AM Central Standard Time,
Edward.P.Miska@nwp01.usace.army.mil writes:
Doug,
It is not the technical issues I am concerned about. I like
the concept technically. But what is the cost of engineering,
implementation, and installation? What is Lee doing working on it?
Who is doing what and what are the costs you expect the government to pay
for?
Regards,
Ed
-----Original Message-----
From: DudleyDevices@aol.com [mailto:DudleyDevices@aol.com]
Sent: Friday, December 17, 2004 9:28 AM
To: Miska, Edward P
Cc: Ebner, David A; LSheldon01@Houston.rr.com; Todd, Wayne A
Subject: Re: 3-D cam block diagram
Ed,
Lee said the flushing should be every 4 hours to equalize the
temperature of the water in the Winter Kennedy piping to the temperature of the
water passing through the unit, in addition to flushing the bubbles and
contaminants out.
The automatic system is to allow that frequency without
this becoming a burden on the facility personnel.
Doug
==============
Ref from prior email I sent Doug Friday, December 17, 2004
9:17 AM
Doug, I am unsure what you are
doing with the flushing system work since it was not included in the contract
and until recently I understood flushing was needed only on the order of months
(TVA person said this) not every 4 hours as you noted. We need to
lay out a clear understanding for this whole area of functionality. That means
I need to know what is going on. It seems the whole effort grew out of my
concern that project operations would not manually perform consistently and a
question as to why it was not automated. That does not equal going
forward on a design. Doug please let us know what the situation is.
Dec
20, I need to by RSLinx SDK, but where to buy it? Englewood Electric has been
so difficult to buy from that I put them on my “do not use” vendor list. I went
to another Vendor in Chicago to buy it, but they had some rules about me buying
from my regional distributor. I tried to buy from Rockwell directly, but they
wouldn’t do that. I had too much trouble buying the RSLinx SDK in the first
place for RSLinx SDK to be a legitimate deal. I told Ed I was getting negative
information from Rockwell’s technical support people (January 1) about the
Visual Basic part, but Ed insisted I use it anyway, and now I ask “why?” Is it
because Dan Perrier recommends it?
10:00. Synopsis
Have made market survey of RSLinx SDK. The local office put me in contact with my XXX software rep.
He was on vacation for 2 weeks, but I called his cell phone to find out if he would be able to provide the level of support I’ll be needing.
After a few days he called back and said no, I should go to Rockwell’s RSLinx support guys for Visual Basic, so I did.
I tried to buy the SDK software from their sales department, but the person who handles that was out for the holidays. They told me to call again after the 1st.
I called the technical support department (case# 3955087) to ask some questions. It seemed a good idea to find out what level of expertise with Visual Basic exists before jumping in.
After I explained what I needed, the first tech rep did not recommend I buy their SDK package because they don’t really support the Visual Basic part of it.
He said there was no new functionality in the upgrade; the necessary “RSAuto.dll“ Visual Basic driver is already in the RSLinx OEM software I already have.
The only thing I’d get from the SDK upgrade is the technical support to get my application running, (which turned out to be non-existent.)
After I explained the level of support I would need, he confided in me that Rockwell didn’t have any practical experience with Visual Basic to provide this level of experience. (All I asked for was someone who had a working version of the Visual Basic interface already running on a computer that I could talk to. He said there wasn’t anybody.)
He Emailed the “partialdemo.zip” file to me, which is the Visual Basic demo that comes with the $1,500 upgrade from OEM to SDK and challenged me to do it myself.
He said he gave me the working version of the Visual Basic demo from SDK.
He said he could give it to me free, but no support would be available without paying the added $1,500 (and he wasn’t recommending this).
Reading up on this on their website, I learned that the RSAuto.dll has been replaced by “rsiopcauto.dll,” the new driver to go with the latest revision of the RSLinx software. This is the one that came with the RSLinx OEM purchased in September ‘02.
The Visual Basic program in “partialDemo.zip” has embedded documentation that references the support documentation file “OPC Data Access Automation Interface Standard.” According to the embedded documentation in the program, this file should be distributed along with the partialdemo.zip Visual Basic demonstration program that the tech rep Emailed to me.
The
problem I’m having here is primarily with Ed. Telling me to do it with OPC is
that I wanted to usethe RS-232 method recommended by Lee Parmeter at SoftPLC,
it would have cost $125 and taken a couple of days. If Ed really wanted a cheap
and dirty proof of concept, his directing me to OPC was a BAD CALL that he
should explain himself on.
The following is the header for the program that makes this reference:
‘*********************************************************************************************
Option Explicit
' PartialDemo - RSLinx OPC Automation
Interface Demonstration program
' -----------
'
by: Christopher Di Biase
'
October 9, 1999
'
'
The purpose of this program is to demonstrait the basics of using the
'
RSLinx OPC Automation interface DLL with Visual Basic 6.0. This program
'
is limited to a single item, and can perform all of the normal OPC
'
opporations on that item.
'
'
For a more complete explanation of the proporties, methods and events
'
included in the interface, refer to the OPC Data Access Automation
'
Interface Standard which is included with the RSLinx OPC automation DLL
Dim oOpcServer As
RSLinxOPCAutomation.OPCServer ' OPC Server object
Dim WithEvents oOpcGroup As
RSLinxOPCAutomation.OPCGroup ' OPC group object
Dim ClHandle As Long ' varriable to
hold the item client handle
Dim SvHandle As Long ' varriable to
hold the item server handle
Const OpcDsCashe As Long = 1 ' used in
the OPC read functions, causes the read to take data from the RSlinx Cashe
Const OpcDsDevice As Long = 2 ' used in
the OPC read functions, caused the read to take data directly from the device.
‘*********************************************************************************************
After working with it for a while, I decided this program was a piece of crap, and a waste of time. I’ll be doing a Google search on Christopher Di Biase to get more information.
I’m finding problems with the partialdemo program. It doesn’t link the .dll program.
The support file referenced above would have instructions on how to setup the reference to the dll in the Visual Basic program.
When I called Rockwell software support again, I was told that Rockwell didn’t have this reference file in their database, and I should go to the “OPC Foundation” website for more information.
I went online to “OPCFoundation.com.” This is a large organization of industrial manufacturers that have prepared standards to enhance compatibility among their products. In my search for Visual Basic expertise, Rockwell’s technical support has deferred to OPC Foundation for documentation on how to use the program that Rockwell Emailed to me. To get any downloads; I had to register with them. They’ll send an email with the password verification.
Ed Miska wanted me to stay with Rockwell because their stuff works. But now Rockwell tells me Ed has overestimated their capabilities. I appreciate their candor.
Now I need to figure another way to get my Visual Basic driver.
I’m considering going to Dan Perrier to ask him to prepare the Visual Basic .dll to Rockwell OPC communication to the SoftPLC. He’d make sure it would work OK. I could barter him some PT Interface modules. They’re worth $650 ea to him. I’d make him 10 in exchange for exactly the driver I’m needing and training on how to use it.
My questions for my next call to Rockwell tech support:
Who is Christopher Di Biase? Was he an employee of Rockwell when he wrote this?
I exchanged emails with Christopher Di Biase. He was an intern at Rockwell working in the computer software department. He wrote the PartialDemo program as a self-test of his understanding of the RSLinx OPC interface, not a formal software effort by Rockwell.
Why has there been no update to the program since 1999? Because it is not a Rockwell certified program.
Where is the linking declaration to the .dll file in the partialdemo program? No answer yet.
Rockwell’s tech support told me OPC Foundation would be the reference used by Rockwell in preparing their Visual Basic interface for RSLinx, and I would be better off to go to OPC Foundation directly to get the documentation on it.
Software arrived on 12th.
Called Rockwell Chicago office, spoke to Mike Baranski, local
manager for sales. He says he’ll look into the problem and get me some help
with documentation. Said he’d call back that afternoon. No call back. I bought
the software from Rockwell, and I expect Rockwell to put the documentation into
my hand. Something similar to the C code documentation would be good.
Continued to study software.
Stop 12:00
Start 2:00 pm
Called tech support again, was very pushy this time, not taking no
for an answer.
Got put through to a guy named Dave in the programming department.
He told me Rockwell doesn’t support the VB - have a nice day. Like everyone
else there, he told me to go to OPC Foundation to get docs.
Went to OPC Foundation and tried again to register for a user ID
so I can download some files. They are
supposed to send an Email from them with password verification, but it didn’t
come.
4
hrs.
Start 8:00
Called Mike Baranski again, he didn’t return my call from Monday,
so I tried him again.
After
waiting for him to come on the phone for over 10 minutes, I asked the
receptionist to let me speak with his boss, Jeff Saga. Told Jeff the whole
story and how I felt Rockwell needed to provide documentation for this product.
Jeff said he’d look into it and get me the help I need. He walked out of his office and told Laurie,
their secretary “If that guy calls back again, put him through to Mike.” So there’s the level of support at
Rockwell.
Monday, January 17,
2005
8:00 start.
Setup workspace for Hydro Software.
9:45 Called Rockwell 440-646-5800, learned how to remove OEM from development system.
Got a Case #4003900.
Moved OEM to target machine.
Installed SDK in development machine.
Looking at the Visual Basic part, the first thing I noticed is the nomenclature they used is unfamiliar.
Went through their program reading embedded documentation. Seems to be enough of it, but the programmer used techniques I’m unfamiliar with. The learning curve gets steep here.
Thursday, January 20,
2005
7:00 start. Studying VB Sample program. There is no documentation for the VB part of this. I had to call Rockwell to find out where the VB Sample program was. It doesn’t show up on the CD, but after installation it’s hidden in an obscure folder, OPC Automation, instead of calling it “VB Sample,” or something obvious. The people I’ve been speaking to on several calls to Rockwell don’t even know about the VB part of this. Last Monday one Rockwell tech support guy said he’d pass my message along to their VB specialist, who would call me back. I’m still waiting.
Dan,
I got the RSLinx SDK
program. Rockwell doesn't support the Visual Basic part of it, just the C
stuff. It's always something. Rockwell is referring me to OPC Foundation
to research Visual Basic OPC interface on the web. Any ideas or ready
references you might suggest?
Doug.
|
Subject: |
RE: ATE-31 Quote |
|||
|
Date: |
1/20/05 3:08:14 PM Central
Standard Time |
|||
|
From: |
||||
|
||||
|
Sent from the Internet (Details) |
||||
If you use Quickbooks for accounting, you may want to try using
Quicken credit card services. We use their service and the costs are not
too bad. We are required by the Government to accept credit cards or we
would not have this setup either.
The following links may be able to assist in the VB code examples
to OPC.
http://www.opcconnect.com/freestuf.php
http://www.kepware.com/Support_Center/app_vb_example.html
http://www.software.rockwell.com/forum/rslinx/messageview.cfm?catid=73&threadid=7685
Regards,
Dan Perrier, P.E.
Friday, 21 January,
2005
8:00 start.
Studying VB6 environment. Reverse engineering their sample code to see how it works.
VB6 has a new tool, the “Object Browser” that is pretty handy for looking at dll files.
This tool shows the arguments to the dll files that are linked to the project you’re working on.
The RSIOPCAuto.dll file is the OPC driver for the Pc. The default location for this dll is in the “c:\program files\common files\Rockwell” folder. I prefer to move all dll files used by a program to the same folder as the program, but in this case we’ll be leaving the dll where it is.
Security is a hidden, encrypted key file on a floppy disk. This file is copied to the hard drive of the computer the dll is to be used on.
Installed PCI modem to get anti virus check and IBM OS updates.
There’s a C book, but no VB Book.
I started calling Rockwell again looking for more documentation. After several passalongs, I called Kristin again. She confirmed there’s no documentation or book for the VB part of this.
11:30 stop
Took 10 days off because father-in-law died.
When I resumed work on February 1, I told Ed that I was dumping Rockwell. He had sent me down another dead-end road at the recommendations of Dan Perrier.
First alterative tried was Kepware. They were no more technically competent than Rocwkell with Visual Basic interfacing to OPC server technology, but they don’t charge $2,500 for their bogus software. I only spent a few days figuring out these guys had nothing I could use.
On February 24, 2005 I switched to Software Toolbox, the supplier whose stuff fits within my skill set. An extra bonus, they take customer service as seriously as I do. They always answer the phone, or return my call within 24 hours.
After I got their stuff working, I tried to get Dan Perrier in contact with Software Toolbox to get the techniques used line up with each other.
Friday March 18, 2005
|
Subject: |
RE: FW: Did Dan call? [Incident:
050316-000030] |
||||
|
Date: |
3/18/05 1:14:33 P.M. Central
Standard Time |
||||
|
From: |
|||||
|
|||||
Doug,
In general I am looking for an inexpensive solution if it is
done in visual basic. If an inexpensive solution can't be attained I will
want it done in C++ for a GDACS tool to use in the future. However,
I am always ready to listen to alternatives with possible improved merit like
possibly using an RS-232 port without OPC, if it is inexpensive.
The only thing that is essential is that the right info is passed
back-and-forth properly.
Edward P. Miska
503-808-4294
From:
DudleyDevices@aol.com [mailto:DudleyDevices@aol.com]
Sent: Tuesday, March 22, 2005 9:30 AM
To: Dan Perrier
Subject: Fwd: FW: Did Dan call? [Incident: 050316-000030]
Dear Dan,
Is that price of $500 to setup Software ToolBox's
ActiveX with an OPC server for the GDACS network good for me too? I'd pay cash
to get the piece I need. Any other alternative I see would cost as much or
more.
The following is a brief description of what we're talking about:
I'll send you the license for the ActiveX from Software
Toolbox and the RSLinx OEM package I bought so you can have them legitimately
to work with.
ACSI will configure the ActiveX and RSLinx OEM server to
work with GDACS using a PC with VB6 you already have in house to communicate
with the SoftPLC through a local LinkSys Ethernet switch while it is networked
with the rest of the system.
ACSI will write a small VB demo program to exercise the
ActiveX module to read from the required locations in the SoftPLC.
For my purposes, no writing from the ITB to the GDACS SoftPLC to
move anything will be necessary; but still put the example of a write operation
into the VB Sample code so I can see how it's done.
When the setup configuration and VB sample are ready, ACSI
will return all materials and give me the VB sample code
and configuration information to allow making this system work in my
computer here.
It looks like we could be waiting for HDC for a while. To get
it moving again now, I'd like to put a little grease on the skids under
your sled.
Best,
Doug
Wednesday
March 23, 2005
|
Subject: |
RE: FW: Did Dan call?
[Incident: 050316-000030] |
|||
|
Date: |
3/23/05 4:14:18 P.M. Central
Standard Time |
|||
|
From: |
||||
|
||||
|
Sent from the Internet (Details) |
||||
Doug,
We have played around with this some and it looks like a day
instead of half a day (it is a little more confusing on how we can save the
configurations to make your side easier). So the price is $1,000.
Sorry for the change. We should be able to get this together within a
couple three days after receipt of a PO.
Let me know what you think.
Regards,
Dan Perrier, P.E.
President
Automated Control Systems, Inc.
12119 NE 99th St.
Suite 2090
Vancouver, WA 98682
phone (360) 737-6654 ext 205
fax (360) 737-6673
dan-perrier@automation-software.com
www.automation-software.com
Thursday
March 24, 2005
|
Subject: |
OPC ActiveX Download
& Registration Instructions |
|||||||
|
Date: |
3/24/2005 11:48:55 A.M.
Pacific Standard Time |
|||||||
|
From: |
||||||||
|
||||||||
IMPORTANT INFORMATION: KEEP A COPY OF THIS MESSAGE
Thank you for purchasing your OPC Data Control ActiveX from Software Toolbox.
We are pleased to send you your order information, links to download the
product and other valuable information.
We hope you will be very satisfied with your software and that you will
continue to use us for your Automation needs.
Name on Order: DOUG ALBRIGHT
SWTB Order Ref: 9009
Part Number: 41276102
License Number: 10110597715-77713d69b0-4684
You can download the OPC Data Control ActiveX directly from our FTP site using
the following link:
http://ftp.softwaretoolbox.com/demodnld/41276101_OPCDataControl.exe
Please print the License Agreement:
http://temp.softwaretoolbox.com/prod_reg/swtb/41276102license.asp?serial=10110597715-77713d69b0-4684
Please read our Important Pre-Installation bulletin:
http://temp.softwaretoolbox.com/prod_reg/topserver/ie6bulletin.shtml
Software Toolbox Technical Support Policy:
http://temp.softwaretoolbox.com/prod_reg/topserver/productSupport.shtml
Our Technical Support Knowledgebase is available at:
http://www.softwaretoolbox.com/Tech_Support/tech_support.html
Your best resource for learning and using the OPC Data Control ActiveX
component is to visit our dedicated product website where you will find many
technical white-papers, how-to guides and source-code for C++, VB and .NET. All
of this is available at:
http://www.opcactivex.com
please look at the section 'Recommended Reading' at the end of this email...
Sincerely,
Kathy Allred
SOFTWARE TOOLBOX - www.softwaretoolbox.com
148A East Charles Street, Matthews, NC, 28105, USA
sales@softwaretoolbox.com
support@softwaretoolbox.com
Recommended Reading to help you understand the product better...
Lesson One: Reading Data without Writing Any lines of code:
http://www.opcactivex.com/Support/Samples_SimpleRead/samples_simpleread.htmHow
to use the OPC Server and Item Browser
http://www.opcactivex.com/Benefits/ProductFeatures/BrowseDemo/browsedemo.html
The DCOM Configuration tool **RECOMENDED-IMPORTANT**
http://www.opcactivex.com/Support/DCOM_Config/dcom_config.html
What is the Purpose of OPCENUM.EXE?
http://www.opcactivex.com/Support/General/OPCEnum/opcenum.html
How do Subscription Reads work?
http://www.opcactivex.com/Support/General/Subscriptions/subscriptions.shtml
When to use Sync Reads vs. Subscription Reads
http://www.opcactivex.com/Support/General/Sync_vs_Subscribe/sync_vs_subscribe.html
How to use the OPC Data Control with VB.NET
http://www.opcactivex.com/Support/General/VBDotNet/vbdotnet.shtml
Friday
March 25, 2005
Saturday
March 26, 2005
Sunday
March 27, 2005
Monday
March 28, 2005
Subject: FW: OPC access via Software Toolbox ActiveX object
Date: 3/28/2005 1:46:08 P.M. Pacific Standard Time
From: dan-perrier@automation-software.com
Reply To:
To: DudleyDevices@aol.com
CC: joe-swatosh@automation-software.com
BCC:
Doug,
We have it working now. Please contact Joe or myself to walk you through
it.
Regards,
Dan
======================================================
Start logging time for
Invoice
Start 12:00 pm.
Original Message-----
From: Joe Swatosh
Sent: Monday, March 28, 2005 11:38 AM
To: Dan Perrier
Subject: OPC access via Software Toolbox ActiveX object
Doug,
Dan asked me to send you a zip of what we have so far. What we have so
far is a sketch, but we believe it to be enough for you to accomplish what you
need to do. As this is really just a sketch, we are expecting to go over
setting things up on the telephone. Please call Dan or me at your
convenience.
Joe Swatosh
Automated Control Systems, Inc.
12119 NE 99th St.
Suite 2090
Vancouver, WA 98682
phone (360) 737-6654 ext 201
fax (360) 737-6673
mailto:joe-swatosh@automation-software.com
www.automation-software.com
Stop 10:00 +8 hours
Tuesday
March 29, 2005
Working
with Joe’s sample VB program and RSLinx server.
Start 8:00
stop 5:00 + 8 hrs.
Wednesday
March 30, 2005
Documenting
with Joe’s sample VB program and RSLinx server.
Start 8:00
stop 5:00 + 8 hrs.
Thursday
March 31, 2005
Switch to
Laptop, I can send it to Joe if I can’t get it to work.
==========================================================
|
Subject: |
Working |
||
|
Date: |
3/31/05 5:42:22 P.M. Central
Daylight Time |
||
|
From: |
|||
|
|||
Joe,
After fumbling with the desktop PC and not getting it to
work, I took a hint from your comment about my using a laptop. If I can't get
it to work, I can mail it to you.
When I put all the stuff: VB6, your demo VB program, the Hosts
file, RSLinx and your config file for it and the ActiveX module into the
laptop and then ran your setup from my notes, the SoftPLC seconds
display on the laptop worked. I was able to add seconds for a second unit
to the form so I believe I've got the laptop working and understand how to
setup the rest of the text boxes.
Now I'm looking at the PC again to see what's different with how
it ended up and how the laptop setup went.
The only numbers available for me to read from the SoftPLC for
head, tail, gate, blade, power and flow are the no input signal
conditions. Head is always 338.5 ft, tail is 267.59, blade is 14.77, gate is
-7.08 and power is not shown on the PanelMate display.
To make this demo better, I'd like to be able to write values into
the SoftPLC registers over the OPC communication just before I read them
back into the ITB program to get some varying input data for the ITB
to make a more interesting bench-demo.
How hard would this be?
Start 8:00
stop 5:00 + 8 hrs.
Friday, April 1, 2005
|
Subject: |
FW: Actuation Test
Equipment Invoice |
||
|
Date: |
4/1/05 6:23:47 P.M. Central
Standard Time |
||
|
From: |
|||
|
|||
Doug,
Here is the Invoice for the prior work. Joe and I will work
up a price on the new requirement and send it over to you. Thanks.
Regards,
Dan Perrier, P.E.
President
Automated Control Systems, Inc.
12119 NE 99th St.
Suite 2090
Vancouver, WA 98682
phone (360) 737-6654 ext 205
fax (360) 737-6673
dan-perrier@automation-software.com
www.automation-software.com
From: Heidi
Ghormley
Sent: Friday, April 01, 2005 4:17 PM
To: Dan Perrier
Subject: Actuation Test Equipment Invoice
Regards,
Heidi
Ghormley
Automated
Control Systems,
Inc.
12119
NE 99th Street
Suite 2090
Start 8:00
stop 5:00 + 8 hrs.
Saturday April 2, 2005 none
|
Dan,
Thanks for the invoice; I'll get you paid soon. Hold off on
another quote for now. The function I was asking for was a "nice to
have" that doesn’t pass the Miska-test; I'd discussed this feature with
him in November. He said no, it wouldn't add enough value. I just wanted to
know how to write back to the SoftPLC registers.
Before you pinch off the first effort though, there are a few
unfinished details Joe was going to get back to me on before we were done.
For example, he was going to figure out the details of switching
to Software Toolbox’s Top Server from RSLinx and was going to show me
how to add more tags to the configuration file.
I can read all the tags needed for the first pass at the ITB now,
Joe did a good job at getting me up to speed fast. The problem I’ve been having
this week is making this work in the desktop computer slated for this job. It
has two Ethernet ports and an internal bridge. Joe’s setup works in my laptop
OK. Now that I have a working server for a study model, it will be easier to figure
out why the desktop isn’t working.
How do you want to get paid your $1k? Would you prefer a credit
card, net 30 or cash when I get it from USACE? I’m submitting my invoice and
status report to HDC Monday, and they pay promptly.
Doug
Sunday April 3, 2005 none
Documenting procedures from Joe.
Monday April 4, 2005
-----Original Message-----
From: DudleyDevices@aol.com [mailto:DudleyDevices@aol.com]
Sent: Monday, April 04, 2005 3:44 PM
To: Ebner, David A NWP
Subject: April invoice comments
Dave,
Good news, I've got the
OPC Ethernet working. It's just like they said; it's very slick.
To celebrate, I'd like to submit an
invoice this week to get up to date.
The items include:
1.) $795 for the ActiveX OPC
Interface for Visual Basic from Software Toolbox. This is the blanket license
so we can use it as many times as we want.
2.) $1,000 paid to ACSI to
configure and setup the ActiveX OPC Server software, 1 channel.
3.) My labor to capture ACSI's
setup and configuration data, program the rest of the channels, and document
the setup procedures for future use. Preliminary setup manual for the RSLinx
OPC Server and ActiveX OPC Data Control will accompany the invoice.
3.) normal recurring charges.
4.) I'll not charge for time
spent working on it, but not making it work. Perhaps I should have subbed
this job out in January (20-20 hindsight). Charges will include only
work productive towards getting the OPC communication working - it
seems fair to me this way.
Best,
Doug.
Start 8:00
stop 5:00 + 8 hrs.
Doug
Vancouver, WA 98682
Tel (360) 737-6654 ext. 209
Fax (360)
737-6673
heidi-ghormley@automation-software.com
Monday April 5, 2005
-----------------
Forwarded Message:
|
||||||||||
Doug,
First
sentence under #4 below doesn't make sense to me.
?
David
Ebner, A/E Contracts
Army Corps of Engineers, Portland, OR
(503) 808-4611, fax-4605
David.A.Ebner@nwp01.usace.army.mil
"The Best Information Leads to
Success"
Start 8:00
In a message dated 4/5/2005 4:52:55 PM Central Standard Time,
David.A.Ebner@nwp01.usace.army.mil writes:
Doug,
First sentence under #4 below doesn't
make sense to me.
?
David Ebner, A/E
Contracts
Army Corps of Engineers, Portland, OR
(503) 808-4611, fax-4605
David.A.Ebner@nwp01.usace.army.mil
"The Best Information Leads to
Success"
|
||||||||||||
Doug,
Here is some info for the Top Server. We think that this should wrap up
the current PO. Please let us know if/when you would like to simulate the
I/O.
The following is from Joe.
Doug,
To get TOP Server working, all I did was install it, run it:
-add a new channel "Edit|New Channel..."
-what ever name you want
-use the Allen-Bradley Ethernet driver
-use the default network adapter
-I accepted all the defaults for Write Optimizations
-add a new device to the channel "Edit|New Device..."
-what ever name you want
-PLC-5 family for the device model
-The "dotted-quad" ip address of the SPLC
-I accepted all the defaults for Timing
-I accepted all the defaults for Auto Demotion
-I accepted all the defaults for Communications Parameters
-on the right pane there was a place to "Click to add a static tag."
-I clicked it
-I added the name "Second" and the address
"S:23"
I added another "OPC Data Control", set the OPC Server to point to
the SWToolbox.TOPServer, set the Text field as before on the Connections tab,
and we were off to the races.
As far as adding tags:
-For the RSLinx Server, just edit the csv "symbols"
file following the pattern of the existing lines
-For the TOPServer, just keep adding tags to the device as above.
Joe Swatosh
Automated Control Systems, Inc.
12119 NE 99th St.
Suite 2090
Vancouver, WA 98682
phone (360) 737-6654 ext 201
fax (360) 737-6673
Writing Software manual for ITB.
Stop 12:00.
Resume 1:00
Stop 5:00
April 5, 2005
|
OK, Let me restate that.
The time I spent trying different configurations and settings,
reading the manuals and waiting for people to call me back with answers was
work, but didn't yield any progress toward solving the problem.
It wasn't until I got the ActiveX and ACSI's input that I started
making some real progress.
I considered farming this out in January, but didn't have a
satisfactory specification of the work I needed ACSI to do.
I'll only charge time that progress was being made. The
labor on the invoice, coming later this week, starts the afternoon Joe
Swatosh sent me his VB sample program.
Seems only fair to me.
Doug
|
||||||||||
Doug,
Thanks for the update.
Would you please send me the program source code and/or any
documentation ACSI provided?
I am guessing what you sent is incomplete or will be combined with
other documentations so the following comments are probably irrelevant but just
in case I thought I would make them anyway. Is the document you sent to
be combined into other documentation you have already produced including a
table of contents? How is a user going to know what the intent of the
document is unless you add something to introduce it such as you stated below
"ITB software installation, setup and configuration manual"?
Thanks,
Ed
-----Original Message-----
From: DudleyDevices@aol.com [mailto:DudleyDevices@aol.com]
Sent: Wednesday, April 06, 2005 10:58 AM
To: Miska, Edward P NWP
Cc: Ebner, David A NWP; Lee.Sheldon@us.army.mil; Wittinger, Rodney J
NWP; Todd, Wayne A NWP
Subject: ActiveX and OPC Server setup and configuration
Dear Ed,
The OPC Server communication is working. The attached is a draft
of the ITB software installation, setup and configuration manual. The OPC
setup starting on page 4 is from the $1,000 to ACSI for the OPC interface
setup. Money well spent.
Doug