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.

  1. We’ve been allowed to connect directly to GDACS, and our LinkSys Ethernet switch is already in place on Unit5 at McNary, ready to use as a portal to connect the ITB into the GDACS system. (When I met with him in September ‘04, Rod Wittinger predicted we’d not get this far.)

 

  1. The OPC connection to GDACS interface method from ACSI is working in the ITB computer. This works reliably and is ready for, and needs Ed’s evaluation.

 

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. Mark Kingstad 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:

 

  1. The values for Head, Tail, Gate and Blade must come from the GDACS transducers
  2. No writing of data back to the GDACS system to avoid possible virus infection
  3. Index Test Box must be able to move blades to facilitate index tests.

 

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?

The following is from my logs:

 

Saturday January 1, 2005

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.

 

Thursday Jan 13 2005

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:

dan-perrier@automation-software.com

Reply To:

 

To:

DudleyDevices@aol.com

CC:

 

BCC:

 

Sent on:

 

 

 

 

 

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:

Edward.P.Miska@nwp01.usace.army.mil

Reply To:

 

To:

DudleyDevices@aol.com

CC:

David.A.Ebner@nwp01.usace.army.mil, Wayne.A.Todd@nwp01.usace.army.mil, dan-perrier@automation-software.com

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:

dan-perrier@automation-software.com

Reply To:

 

To:

DudleyDevices@aol.com

CC:

 

BCC:

 

Sent on:

 

 

 

 

 

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:

sales@softwaretoolbox.com

Reply To:

tech@softwaretoolbox.com

To:

dudleydevices@aol.com

CC:

kathy.allred@softwaretoolbox.com

BCC:

 

Sent on:

 

 

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:

DudleyDevices

Reply To:

 

To:

joe-swatosh@automation-software.com


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:

dan-perrier@automation-software.com

Reply To:

 

To:

DudleyDevices@aol.com

 

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

 

Subj:

Re: FW: Actuation Test Equipment Invoice 

Date:

4/2/2005 8:49:25 AM Central Standard Time

From:

DudleyDevices

To:

dan-perrier@automation-software.com

 

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

 www.automation-software.com

Monday April 5, 2005


-----------------
Forwarded Message:

Subj:

RE: April invoice comments 

Date:

4/5/2005 4:52:55 PM Central Standard Time

From:

David.A.Ebner@nwp01.usace.army.mil

To:

DudleyDevices@aol.com

Sent from the Internet (Details)

 

            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"

 

 

 

 

 

 

 

Subj:

Top Server 

Date:

4/5/2005 11:11:43 AM Central Standard Time

From:

dan-perrier@automation-software.com

To:

DudleyDevices@aol.com

CC:

joe-swatosh@automation-software.com

Sent from the Internet (Details)

 

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

 

Subj:

Re: April invoice comments 

Date:

4/5/2005 5:02:24 PM Central Standard Time

From:

DudleyDevices

To:

David.A.Ebner@nwp01.usace.army.mil

 

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

 

 

 

Subj:

RE: ActiveX and OPC Server setup and configuration 

Date:

4/6/2005 1:33:10 PM Central Standard Time

From:

Edward.P.Miska@nwp01.usace.army.mil

To:

DudleyDevices@aol.com

Sent from the Internet (Details)

 

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