OkiePC

Are you able to use RSLinx with the ethernet connection to get online with the 5/03? In order to verify the serial side of things. Also, did you choose the right type of MSG? I think it should be SLC Typed Write working from memory.

If the current changes when you replace the meter with the PLC input, then something is wired wrong or you have a bad input point....but a bad input should not be able to cause an increase in current...keep your meter in series and tell us what happens.

It is pretty safe to say that newer hardware will run the older .mer file just fine. On reboot you should look for the firmware to be displayed, but beware there are a lot of other numbers that aren't it. I think you can drill into the Terminal Settings menu and find it there as well. You may want to wait a few more days, the PV600+ is silver series and there is a better faster drop in replacement available for order soon.

I would carefully inspect the wiring first, unless this error is always proportional like you describe. I have not used Controllogix motion, so I can only suggest you search for scaling in the literature and terms like encoder quadrature multiplier. Many servos offer a place in the basic configuration of how the raw encoder signals are counted, and then further they may be scaled to engineering units in the VFD parameters perhaps you are pointing at a scaled value rather than raw encoder counts?

I mainly wanted to point out that patch for the zooming issue. As for virtualization, I had to figure it out with help from forums, and ended up getting Windows Virtual PC to work okay. My IT department uses Microsoft HyperV for virtualization because it comes with a shedload of free liceneses. For that reason they didn't want to let us use VMWare, but they did say if I couldn't make the (free) Virtual PC or HyperV to work they would come up with a WinXP license and allow me to download and run VMWare If you have Windows 7 Pro, you can run virtual PC without having to come up with a WinXP license for it. And, if you decide to give this a try, I can share what I learned which may be helpful... I really hope that we are able to eliminate our dependence of FactoryBalk altogether some time soon. 100% of our A/B hardware HMIs are now obsolete and I am trying to go Red Lion with those, and our half dozen scada systems can migrate to Ignition.

Now that you have FcTMeViewStudio 6.10 plus patches running (hopefully in a virtual machine) make a restore point, take a snapshot, image...but first you may want to check for one more bug if you work with the PV600+ on a desktop with a big monitor: If you are editing a PV600+ sized window and zoom in and edit objects, weird things may happen to them like they disappear to the left of the display where you barely see the right most "handles" but can't quite grab them or normal buttons become gigantic (bigger than the whole screen). http://www.plctalk.n...ead.php?t=75188 Even with the latest Patch Roll Up dated well after the fix for the above problem, I had to apply that patch manually anyway, but it did work. I don't think the problem with zooming occurs with other target display sizes, so if you don't use the 600+ you can probably skip it.

Two comments: 1. Look up tables are elegant. 2. Rolling queues. I didn't flesh out all your code, as soon as I saw you erasing stuff...just increment a pointer to an array or arrays and stuff the new data there. Only erase the oldest as you overwrite it. If your array holds 99 days worth of data and you only need two, I see no problem with that...typical software engineer overkill if you ask me...someday, that stale data might save the day...if you need to compare each time new data gets written to see if the month changed, just use an offset from the present pointer. Never reset the pointer or erase data (okay once at commissioning). yes, you must deal with rolling over in your pointers and offsets but, to that I say "so what?" This data never moves, so you can go back and manipulate parts of it, fill in more information in your table as the system provides it, build a rolling message buffer to send it somewhere else for archiving and be able to tolerate lengthy communications interruptions without a loss of data. Okay, [/soapbox = rolling queues aka revolving queues aka rotating queue]...

WHen I first was exposed to Controllogix, Ethernet and Controlnet were about the same speed and Ethernet IP I/O was not yet fully trusted, although even at that time, around 2000, could be configured to be failsafe and as reliable as controlnet without the hassles of scheduling, coax media, and expensive adapters. Today, ethernet IP hardware is so much faster, that you are right, it is not uncommon to fins a network that is suffering from collisions and re-tries but exhibits no symptoms, due to the overwhelming speed, the right packet may get there late on the third try but in plenty of time to satisfy the required control requirements. I would view controlnet as a dying if not dead branch and definitely shift toward Ethernet IP technology. I like controlnet, If you can see the LEDs and set a node number you can troubleshoot and repair it most of the time. It is simple and wokrs or doesn't.. Ethernet IP, on the other hand, does open you up to a whole new layer of potential mystery root causes which requires you to put more thought into network design and hardware selection and configuration.

If you want more than a half dozen or so copies, contact a local print shop. they can make you up some nice rugged softback manuals in whatever style you can imagine. I like the square punch plastic comb binders with textured opaque covers: http://www.officedep...nes/N=5+509742/

I don't know if the checkdrives system variable still applies with Factory Talk Activation Manager. With version 3.4 I think, there are improvements to the user interface. I think 3.5 is out now. I have had no problems having a newer server with older clients during the process of updating multiple machines' FTA version. I recommend running the latest FTA manager. In the client settings, you can specify the order in which license servers are searched. If you are hosting your own license (node locked or concurrent but all on one machine), make sure the path to the local license is the first one in the list. In most all cases, I think the local path should be first...you don't want to always look for a network resource, for example, that might only be present half of the time. Also, make liberal use of the refresh buttons and even the refresh server buttons after adding licenses. This might just be a graphical way of setting the checkdrives variable, but I think you want to do it within Factory Talk Activation Manager. If you have trouble, you can make sure it is the only path listed. We use a separate PC as a license server and still have a few node locked, so there are two paths on most of our machines. I am not sure if licensing is related to the sluggishness, I have not seen this issue except for perhaps five minutes or so after adding a licence or making changes to a client. I run versions 16 through 19 and the concurrent license is on a server PC on our local network. My counterpart blew up his PC and had to migrate to a new 64bit box last week. After getting it all set up, his license kept going to grace period The license was freely available showing up in the list on all our machines but his would not go get it. Finally he figured out he had to go in and edit the license number he'd entered during installation of RSLogix5000 to match the one in the server list..the number he had entered was the actual license from the old machine and had worked before...his old machine was the one that had the evrsi license, but we had made it concurrent and upgraded it..perhaps some leftover tidbit of the evrsi license scheme was still working on his old box? And even then after all was refreshed and available, license numbers matching, it was a solid five minutes of head scratching before the thing finally just started working and the delays went away.

The moisture sensor appears to be a passive 2 wire device. You supply it with power at its "+" terminal. It's "-" terminal should really be called a return signal. The return wire number 2001 signal passed through terminal number 28 and then is applied to the positive input on the PLC analog card. This moisture signal return will be a voltage or current that is proportional to the moisture content and interpreted to a value by channel 0. The circuit is completed by connecting the power supply low side to the common for the analog card with wire N11. The draftsman could have kept the two sensor wires shown individually. Showing them in a cable makes it a little harder to follow.

You will need t o change the IP on the PV+ at the terminal itself. I believe you might be able to edit the shortcuts to devices (PLC IP address) from the screen too, but if not, you will need to do so in Factory Talk Studio and make a new runtime file for that PV+ (be sure to make the new file for the correct firmware running on the PV+). I think you can change the Compactlogix on the fly, not sure if any of your devices require power cycle after changing ... I don't think so, but it wouldn't hurt to make sure the changes are all properly saved and that lost connections to the old IP addresses are flushed out of buffers. MAKE sure that your IT department understands Ethernet IP I/O traffic and what it WILL do to an office network if not properly connected to the business LAN. The use of a managed switch between the two systems with IGMP snooping enabled and a querier working is highly recommended if not required.

I don't think so. If you had completely lost communication you should see errors for every address the PV tries to access and they would be worded differently. What you are seeing indicates that the PV is able to communicate but is getting a response from the SLC that at least some of those addresses are not there. If I had to place a bet, I would suspect that the SLC lost its program and has a default program now, and in the default program F8:0 would be the only element in the file. (There would be no F8:1, F8:2, etc.) Even if faulted with no program, the IP address may remain intact and the SLC will continue to communicate. Of course if this happened, the outputs will all go to a fault state and the logic will not be executed. So if the machine still works except for a few PV errors, then my bet is a losing one.

If the final goal is to balance the run time, then you should simply measure that, and then use comparison statements of their run times. This will have the effect as you stated to balance them and maximize off time duration. From there there are a couple of approaches I can think of to create a queue or next up bit for each pump. You could simply populate an array with the sequence based on total run times excluding any running or unavailable pumps. The lowest total run time would be next up during the transition to add one in your sequence, an array tag something like PumpSeq[0]. To get the right values in there might be best done with a loop, but for only four iterations the straight logic should not be too bad. I have done this for a three pump rotation in a Micrologix1000, and it was not too complex. Let me hammer out some Microlite500 tests for a four pump-er and get back to you.

I don't know if I have posted it before, but I did this sort of "poor mans servo" with V/Hz drives in the late 90s with really good success. I used one enable signal and a bipolar output +/-10vdc. I used a timer, dividing the acc by the pre to a float. I used distance for the ramp down, which ended up with a nice smooth deceleration. Same type of math: position_error/decel_distance, clamp between max speed and min speed. Set the drive accel and decel times to the minimum, and always make sure you ramp the value properly in all modes so you don't jerk the hell out of it!

I would start there. You may want to keep the PID but only give it a very small influence on the recorded speed that works at that command speed. Think of the command speeds as recipe names for now, to avoid the lag caused by the PID having to do too much of the work. That gets the machine fixed right away, with a look-up table, as long as there aren't too many different command speed settings being used. The data gathered can be used to sit down and write the CPT as suggested where you can triple check it and test it before you download the concise version. Correct me if I am wrong but is there a FBD block for this? I only have a standard license at work.

IN the olden days we did a project where we needed four of the same set of routines. We just wrote all the code with program scoped tags, and literally copied and pasted them between instances of the editor. I think it would prompt you for a new name if they were duplicate names in the destination file. At that time, the turn of the century actually, afterwards some of the tags had to be changed to controller scope for HMI access. This was pretty painless using search and replace very very carefully. With newer better HMI/Scada drivers you can access program scope tags directly, and only need to make controller scope tags for interlocking amongst programs.

And also give part numbers for the hardware any time a panelview is involved. we don't know if you have a standard or a plus.

After you make changes, you should save them by closing the trend and then saving the RSLogix500 file.

I upgraded 19 tire machines (times two sides per machine) from Tenor Stepper (mechanical drum steppers) to SLC 5/04 on tire assembly machines, I was very happy to see the last one land in the metal bin. I had to do the job in four hours per machine, so I spent about 4 months "sitting on my bucket" getting good at panel rewiring for half the work day at least 3 days per week. The first one of course took almost six hours, all the I/O wiring had to be pulled back and rerouted, much of it replaced then the logic debugged. There were six slots of I/O something on the order of 40 outputs and 40 inputs. After that, I could do them in three hours, once I knew which wires to toss aside and came up with a quicker ways to replace them in pairs and threes. I was known to have a big cardboard box full of wire and relays when I rolled my computer cart away from the job. I bet I personally filled three medium sized dumpsters with old hardware in those 4 years.

I am averse to board level components hanging around industrial terminal blocks when I can buy a more expensive package that "bolts in". Seriously' date=' I despise resistor arrays on terminal blocks and caps dangling...give me a din rail mount box with all that stuff protected...[/size'] http://www.google.co...erp.dUTK_iP4NBA I suggest in most cases, pony up for the 44 pin cable and not the drive mounted break out board.

Ken, it looks like those in particular appear as if being viewed under the Ethernet/IP driver. Could it do that by having the IP addresses in the browse list appended with ":EIP"?

Never use a duplicate IP address on the same network...it can bring down a network...there are ways to use advanced switch management tools to allow it. Search here and and plctalk.net for IP addressing schemes. I am not an expert, but I have read some great "articles" on the subject at these forums. You will need to segregate I/O traffic from remote monitoring computers with Ethernet I/P, so ensure that this is considered and that a manage switch port isolates the local machine network from blasting the office printer with I/O update broadcasts 200 times per second... As for sharing data, I think Bob was thinking of doing so for the purposes of realtime control among different controls. I read that you want a centralized recipe with a good backup system. Park a Red Lion HMI or data station on the network and stick a 2GB flash card in the socket and manage the recipes there, centrally, and write the data to all the machines recipe data files.

It's probably some dude's favorite instruction. I seriously doubt it is an industry standard. I work in food too, and have found a much lower level of skills involved in the programs I have looked at from OEMs in this field. Some of the programs are okay, but most of them are pretty amateur, some of them downright terrible. I have one system full of sequencers...I wondered what they were doing with all those SQO instructions...turns out they are using them to compare the real time clock with a list of operator settings for defrost times...I would have just used indirect addressing on the input side of the logic, but as they say, "there is no wrong way to program."

Was this system working before (I assume so, since it is old hardware)...? It has been a while but I will try. Your error is with a DH+/RIO channel. IIRC, Port A and Port B as far as the S-Class will be in reference to the serial ports, not the RIO channel. DH+ and RIO are pretty solid systems. Almost every failure I have seen was the result of a wiring, shielding or termination resistor. I did have a machine running for about a month, then I got a RIO error and found that the original programmer made no accommodation to reset that error in his GML diagram. I had to power cycle the whole machine to get it running until I could make the necessary changes. I doubt this is your case if the machine has been running for any significant length of time. If you are seeing retries and errors in the channel stats, then you likely have a wiring issue. If the wiring and terminations check good, I suppose it could be a faulty device on the network, but that is the last thing on the list of suspects in my experience.