Keith Menges

MrPLC Member
 View profile  See their activity

  • Content count

    49

  • Joined

  • Last visited

Posts posted by Keith Menges

  1. Posted

    That's because cost/benefit analysis says it doesn't have to. The cost of failure in general industry isn't high enough. In my daily job I don't have the lives of three men, the GNP of half the world and the hopes and dreams of a nation riding on my decisions. If I did I would be doing much more true engineering. The cost of failure for these people was extremely high and they didn't have any previous experience to lean on. It was a truly incredible endeavor. I wonder how many people had to bow out because the pressure just got to be too much. Keith

  2. Posted

    You can look at it one of two ways. In the English system, dividing weight by gravitational acceleration gives you mass in slugs, which is the customary english unit of mass. Or you can divide linear acceleration by gravitational acceleration to give you acceleration in G's. Ultimately you are trying to satisfy the equation: F = m*a and get the units to work out right. Keith

  3. Posted

    Looks like a pretty reasonable solution. Using the master encoder as a feed forward command value and just using the PID as a trim will definitely help. Be a little careful with the feed forward value. The PID will only allow for positive correction the way it is set up now. If the feed forward value ends up a little too high you have no way to get the slave speed back down. Keith

  4. Posted

    I guess my question is specific to this situation. Why the flood of messages when you connected the 5/05? It should only speak when spoken to unless it has a slew of Ethernet MSGs in the program. Or do you have an HMI connected to it via Ethernet? Even then they usually don't request that much data. Of any of the AB products you can put on a plantwide network I would think the 5/05 would be one of the safest. Keith

  5. Posted

    As long as your timing mode is set to periodic the instruction will use the Task period to calculate the integral. So task period times won't affect the integral sum. The easiest way to evaluate what will happen with different gains is to look at what happens to a unit step input. If the integral sum starts at zero, the integrator gain is set to 1 and you make a zero to 1 step input to the instrruction the output of the instruction will be 1 after 1 second. It will be 2 after 2 seconds. Taking the same initial conditions except for setting the gain to 2, the instuction will output 2 after 1 second and 4 after 2 seconds. Notice that the gain is applied to the input prior to summing. This means the gain won't affect the limits, only rate at which the limits are reached. What are you using the instruction for? Keith

  8. Posted

    I don't think Peter is advocating using an accumulator instead of a variable displacement pump. I think he is advocating using an accumulator in addition to a variable displacement pump. In that case you could use a smaller pump and motor and allow the pump to refill the accumulator during the dwell time. This would have the dual benefit of providing better response as the pump compensator doesn't neefd to try and react instantaneously to an increase in flow and the idle energy loss will be lower with the smaller pump/motor combination. Keith

  9. Posted

    speakerman- I'm pretty sure that will work. However, playing the devil's advocate (as I am wont to do) I think you have a possible race condition on the reset latch. If the N/C Reset contact in the Set rung starts to open and drops the Set relay befor the N/O Reset contact in the Reset rung can pull in the Reset coil won't latch. Granted, I'd have to be standing on my head pressing the button with my toe on the fifth Tuesday of the 6th month during a blinding snowstorm for that to happen. Keith

  12. Posted

    That depends on your subnet mask to a certain degree. However, you would be pretty safe with 191.190.191.XXX, where XXX is anything other than 9, 0 or 255, assuming this is an isolated network. If you type 'ipconfig' at the command prompt you will see what your laptop is using for TPC/IP settings. Don't even bother doing anything with RSLinx until you can ping the plc. It would be a waste of time. Keith

  13. Posted

    I suggest you read some of the posts here, especially the sections on graphical modelling of the heat exchanger as well as the section about determining gains from the model. I think it will be pretty helpful. However, I don't think the information you have at this point is enough to go on. You will probably need to perform a more structured test. Keith

  14. Posted

    You need to be a little careful using true torque control, that is providing the drive a torque command. If the web breaks and there is nothing for the motor to pull against the motor will accelerate to very high speeds. You may be better off operating in velocity mode with a torque limit. At the very least monitor the speed feedback and if the feedback is outside of some expected range shut down the drive. How well torque control works on an unwind largely depends on how much of the tension the drive system 'feels'. If you have significant drivetrain torque losses relative to the torque needed for tension torque control becomes very problematic. The torque command is simply: Desired_Tension(lb) * RollRadius(in) / GearRatio / MotorTorqueAt10VDC * BitsAt10VDC You may want to also offset this by the known drivetrain torque losses. Keith

  15. Posted

    I don't have the information in front of me right now to really look this up, but this might send you in the right direction. As you have seen you have the data bit speed to support what you are trying to do. However, CNet with not allow an unlimited number of connections per NUT. If you have six devices with a 10msec RPI running on a network with a 5msec NUT, CNet need to schedule three connections in a single NUT to get that to go through. That may be where you are getting stuck. Try to set your per module RPI to 6 times your NUT. In your case this would be 30msec. That should be OK. Keith

  16. Posted

    While I tend to break my own rule, I try to keep selected jog functions hardwired. It is too easy to slip off of an HMI-based jog button while you are looking at the axis you are jogging. I say 'selected' because trying to put all the jog buttons in hardware will tend to add alot of buttons. I have thought about doing an axis select on the HMI and having a single jog pushbutton but I think that would get a little confusing. Outside of that and e-stops, everything goes on the HMI. Keith

  17. Posted

    I think the PLC will get a little upset about multiple labels with the same reference value (2 in this case). I don't know if this is just a typo, but if it isn't you need to revisit this. Also keep in mind that a label is not a point of exclusion. It is just a location the program will go to and begin executing normally from there. If you have multiple labels in succession and you jump to the top label, the code following the other labels is also going to execute. The only time the code will execute only one section is if the code jumps to the last label in the list. The AB PLCs don't have a program method that exactly matches up with a 'function' from something like C. A jump to subroutine is probably as close as you could get but it isn't exactly the same. Also keep in mind that if you jump over any rungs they are not executed. That means outputs will stay in their last state unless the code specifically sets them to another state elsewhere. Be extremely careful with this as it can cause some serious heartburn. My general feeling is that this isn't a real good application for jumps and labels. Not that it can't be done. It just won't be real clean. A subroutine is a possibility but would take a little babysitting also. You are probably better off just doing the code inline and conditioning it as necessary. Keith

  18. Posted

    I know this is true on the SLC series. I thought the PLC5 was built as a two processor system. The logic solver was separate from the communication processor. This tended to keep the overhead timeslice pretty short as all it needed to do was hand I/O data off to the comm processor and then move on. It's also why immediate I/O queries took such a toll on scan time. the logic slover needed to wait for new data before it could proceed. The same would be true of rack mounted comm cards. All the rack mounted stuff was buffered. However, for serial or DH+ I thought the comm processor directly accessed memory as required. So you could get a change of data part way through the scan. Keith

  20. Posted

    Actually, both the COP and CPS will complete fully before moving to the next rung. A simple test is to trigger an incremental copy (COP, Test[0], Test[1], 100) followed by a move (MOV, Test[99], Result) with a oneshot. If the copy doesn't completely finish first you will get variable results in Result. The difference is that the CPS instruction protects the data source and result from being written to or read from anywhere but the instruction itself. The CPS is a required adder due to the asynchronous access that the CLX allows from just about anywhere. Actually, I think you could run into the same issue on the PLC5 with communications. Keith

  21. Posted

    In case you haven't received an answer: The time value is the value of the WALLCLOCKTIME. This is a number of microseconds since midnight Jan 1, 1972. I don't know of any slick converter for this in the PLC. There are probably a whole slew of small apps on the Internet that will convert this for you. But you might be out of luck as far as displaying it goes. Keith

  25. Posted

    Stefan- I don't have anything available I can send you. But I may be able to offer some pointers. I don't know how familiar you are with global data transfer so I may give you some info you already know. In order to use the global data function you need to have all the PLCs sharing data in the same project. Also, all PLCs in the project must have their system data downloaded after a global data configuration change. Double click the MPI icon in the project under Simatic Manager. This will open up NetPro, which you use to configure the network interfaces. Make sure all the PLCs that you want communicating have a connection to the MPI link across the top of the page. If you right-click the MPI line a drop-down menu appears. Select 'Define Global Data' and the global data editor will appear. You will see a table of empty rows and columns. Left-click a gray column header to highlight a column. Then right-click the highlighted column and left-click 'CPU'. Select the PLC in your project you want to associate to this column. Repeat this for all the plcs you need to transfer data to. Left-click a cell in the table to enter the addresses to transfer. The rows in the table define a single data transfer. In any row only one plc can send data but any number can receive it. Not all plcs need to be listed in any given row. This allows you to transfer to one plc or many plcs as you need to. You define which plc is the sender by right-clicking the cell containing the sender address and making sure the 'sender' selection is checked. Again, you can ony have one sender on any given row. The sender is indicated by a > symbol to the left of the address. So as an example: Simatic PLC 1 Simatic PLC 2 Simatic PLC 3 >MD100 MD100 DB10.DBD1 MD104 MD104 >DB11.DBD1 >DB12.DBW2 MW40 In the above example: PLC1 sends MD100 to the defined locations in PLC2 and PLC3 PLC3 sends DB11.DBD1 to the defined locations in PLC1 and PLC2 PLC2 sends DB12.DBW2 to the defined location in PLC3 only You can continue to build up the table as required. Keep in mind this is NOT a very fast transfer method. And the more data you move the slower it gets. It is also not acknowledged so you really don't know if any given station gets a message on a given scan. I hope this helps. Keith