hakko808

sorry for the confusion. I guess I saw similarities between applications. Fill a vessel with high pressure air, monitor, then fill with low pressure air. In his case is a casting, in my case is a tire.

You bring up a good point on the subroutines. I was assuming that the object was to keep the average of the accumulators availiable at all times rather than just occasionally. I guess it would depend on the specifics of the application which were not included in the original description. I tend to avoid subroutines when possible since the overhead consumes scan time. The marble example seems close to what I am referring to. Subroutines have their place, but I have seen programs where they seem overused.

Should work fine, but at 300 PSI I would hope that the casting is enclosed in a safety cage to catch shrapnel. Been asked to look at reworking a tire machine to seat the bead. Only problem I see right now is getting a reliable reading of tire pressure during fill since gauge seems to read a lot higher until fill valve shut off.

I would guess that it is just a matter of the 422 being loose enough to still detect the 232 high/low levels. Same thing has been noted using 485 networks without a pic box in other posts here.

You may want to consider just writing out 29 seperate rungs since it would be a bit easier to follow and save the time penalties of using subroutines or the for next loop. If the sum would cause overflow error consider using long or doing the division first and storing the running total in a float (if availiable).

Without seeing the code it is tough to tell if what was the purpose, or even if in fact it was done as you recall. Sort of odd to me that an idicator on a panelview would use an output rather than a bit, but I have seen it done on older systems were memory was tight and the unused output memory for a slot with an input module was used. Not my style, but it worked. Did you question the vendor? Does the device work as it is supposed to? I must admit that I have used rungs with duplicate outputs as a quick way to force a bit without having to have the red force light on or edit the original logic. When the problem was fixed then just delete the temporary rung without having to reenter the original logic.

I have had a few odd problems with xp and the latest rockwell software. A clean install of xp seems to work best since uninstall does not seem to get rid of all the bits and pieced from older versions. There are also some compatibilty issues with older versions and SP2. For CPR6 there was a set of patches. I do not believe that products before CPR6 are officially supported under SP2. Mixing products from different CPR versions is a crap shoot at best.

Having the same output in two places can cause problems you were having. The way the scan cycle works input states are read, the program then executes sequentially, then the outputs are set. Whatever the last state computed for a given output is the one that shows up. For the most part other bits are modified as each rung is scanned.

Should be able to make multiple refereces to RTC, if not then perhaps you can move the data from the RTC into an INT file at the start of the scan and then just reference the INT in subsequent rungs. Keep working at it, one of the best ways to learn.

I would recommend getting the specified Belden cable. Mixed results with other brands that were supposed to be equivilanet especially if using higher speeds. Check out ABs wesbsite for some installation guides for proper layout and termination instructions.

Don't forget to install the firewall patches for XP service pack 2. If you are still in support you may want to consider going with CPR7. I would ditto the previous comments about dumping the PIC for a UIC and trying to get a unit with a real serial port. Floppy drive can be handy as well at times for older files and old style software activation. DVD burner is not a bad idea to consider either as files continue to get larger and larger. About the only other thing that comes to mind is that I recall reading that the A series of PCMK cards does not work with some of the newer laptops due to protocall change over the years.

I have had fairly decent luck with RSView32. RSViewME/SE is a different product and at best a beta version. What little bit I have worked with Wonderware, I found it stable and fairly straight forward to modify but never had to start from scratch. Big disadvantage I have heard of is price.

Another option I have used is a counter driven by a free running timer. I set the counter to the overall period I want to repeat, and use the counter done bit to reset it. I then use compare instructions (GRT etc) to set the duty cycle(s) of the output. For more complicated outputs I set up an array of bits with each bit representing the smallest time increment I need. Then use bit shifts driven by a free running timer reloading one end of the array with the bit being shifted out of the other end. Set the bits with the desired output pattern and drive the output from one end of the array. One word of caution on either method is that accuracy is limited to scan time.

My understanding is that RIO is essentially obsolete and has been replaced by the newer networks previously mentioned. I still some of the 1794 flex I/O in a couple of plants that have existing infrastructure, but I have taken quite a bit of crap about it.

I am going through an "upgrade" to CPR7. Seems as if the only way to get rockwell's software to work properly is to start from scratch and do a fresh install. This is the second upgrade with similar results. Rockwell software is like a cancer with bits a pieces all over the place and only certain bits play well together. Too bad they do not test before shipping. Another day wasted with tech support and I am back to my original plan.

I am not aware of a ethernet to dh+ adaptor/bridge, but have a similar issue. Options I have looked at so far are ethernet to serial (net-eni), and swapping 5/04 with 5/05. In my case 4 5/04s coupled via DH+ to a couple of PCs running RSView 32 via a PKTX-A card. PCs are getting a bit long in the tooth, the A version cards do not play well with new computers, B version cards are a bit pricy, but swapping all 4 5/04s with 5/05s and pulling new cable is not cheap either.

Maybe this will help.

What are you listing requirements? Unless you are willing to send any homemade circuits in for testing and pay the appropriate fees, you may be stuck finding something off the shelf.

Is it possible that the printer is set to grayscale rather than B/W? I have had problems with some printers printing certain colors very light.

I did not realize this could be done either. May be something unique to the PV300 micro. Further reading in the same paragraph states that you should already have the required firmware and software included with your panelbuilder 32 software. It is probally buried in a folder on the CD.

If I recall the 1400e software will handle file uploads and downloads from the older 1200 type panelviews if the firmware was past a certain revision even if they did not offically have the e suffix. If I also recall once in 1400e software it could be used by Panelbuilder 32 for use with that series of panelviews. AB claims that RSViewme will import these files, but realistically while it may technically read them, I have found the amount of rework needed to be equivant to starting from scratch. I know the couple of older units I had to work with were one firmware revision shy and I ended up doing the editing in PDS, but was able to use 1400e software to do a bit of reverse engineering to document bits, but not do any uploading or downloading. Also from the for what it is worth department, I was able to get PDS to work under windows 2000 on an older gateway laptop, but not under windows xp on the newer dell laptop. Editing and viewing worked fine on both, buth the xp machine had very flakey coms through the serial port for uploads and downloads. I supsect and xp issue since I have other software that just will not work via serial port with xp, but could be a hardware issue as well. I keep forgetting to look to see what versions of PDS are sitting around. If you still need it let me know.

Be carefull, using pine could void the warranty ;)

3-520459-3 looks like the number for a 8 conductor socket with C style keying in the Medar. AB seems to use the A style Keying.1-520459-3. As others have pointed out there could be a minimum order issue. I generally do not pay too much attention to Digi-Keys minimums since they have always managed to get me what I need. Usually just a matter of waiting a week rather than the following day. No luck on the AB mini din. Looks like just a difference in the metal stamping so far. For now I will probally just take a dremel to a standard connector. Not sure why AB feels the need to go from 17" to 2 meters with nothing in between and not offer field connectors.

Well I looked at the connector on the pic module and now understand what is being looked for. It appears to be an SDL type connector. Attached is some basic information I found. It appears as if P.N. 1-520459-3 or 5-520459-3 would be close to what you are looking for. About $3.50 special order through digi-key. The difference seems to be what AMP refers to as Key ID letter. On the PIC I am looking at this letter is printed on the top of the part and molded into the part if you look into the socket. The one on the PIC is an A style, but the Medar ones you need may be a bit different. The data sheet does a decent job of documenting this. 520459.pdf ENG_SS_408_9072_A_1_.pdf

While each application is a bit different, in your applicaiton would it be feasible to enable/disable the coms to the machines in software rather than physically pulling the connector? Perhaps via a PV maintenance screen or add a discreet input from a key switch?