IamNotaCat

MrPLC Member
 View profile  See their activity

  • Content count

    11

  • Joined

  • Last visited

Posts posted by IamNotaCat

  2. Posted

    Max Speed is about 200 FPM, with a 12" wheel It would mean 3.33 revolutions per second. I just don't understand how the counting goes period on that one. On old HSCE counter on my 1024 PPR pulse tach with a quad encoder, it would count 0-1024 and reset, so I had a GEQ 1000 with a one shot to increment a counter saying it ran 1 foot. Since it resets at 1024 the next run through is always 1024 pulse counts before it gets back to the 1000, kept a pretty accurate count.

     

    With this things position value, how does it reset? Am I going to hit overflow or does it automatically zero out at max value... which was 0x3FFFFFF I believe. This means even if I did 1024 counts / rev and maybe modulus the position with 1024 to get a 'Rev' count which would be a footage count, at max I could store around 65,000 before maxing out the value. Would I need to just store that value, trigger a position count reset, start counting again, and do a summation?

  3. Posted

    Good Morning,

    I am considering during an upgrade attempting to use a 842E-M Ethernet IP encoder. I see I can configure it to read both position and velocity. For my application, I want to know total product ran and current line speed. The velocity seems pretty straight forward. If I have a 12" tracking wheel, and I set it to Rev/Min, then I essentially should have a direct Feet Per Minute (FPM) readout from the Encoder.I.Velocity tag (I hope). The counter part is what I am having trouble understanding how to configure from the manual. (Unfortunately I need to make sure this will work before I can buy one, so I can't bench test). 

    So say I set Resolution to 10,000 counts per revolution, and revolutions' at 1  (Maybe even could swap to 842E-S now that I think of it). My position should count up 10,000 times per 1 revolution, and that would tell me I've ran 1 foot. On my old SLC 5/04 with a 1746-HSCE2 card, I could roll over back to 0 after my count and just count up a counter every time. I can't find any sort of 'Roll over' or definitive information in the manual about this. It seems most application examples in the manual are expecting back and forth applications of some sort. Of course, I could just do a modulus command or something like that to keep track, but then what happens when the max position value is entered? The max value of the position counter register at 10,000 counts would hit overflow by 6100 feet ran. 

     

    I am clearly missing something, has anyone done a similar application before? 

  4. Posted

    2 hours ago, LMBrian said:

    I haven't used the Click PLC but have used the Productivity 2000 and 3000 series. They are pretty good too.

    I've also used a range of their relays and solid state relays and have had no issues at all with them. 

    Thank you very much for the incite! I've been reading that their products hold up well. I used one of their GS4 VFD's and was quite happy, so wanted to start trying to use other products they have. 

  5. Posted

    2 hours ago, Joe E. said:

    The 1747-AENTR is in "active mature" status, which means they still make it but they don't want to. It takes the place of the 5/04 CPU and turns that rack into an EtherNet/IP I/O slave of the Control/CompactLogix. I looked briefly at it last year. It would have worked well in my application since it was all digital I/O but the analog modules could get complicated. If you can afford the time, I think it would be better to swap out all of the I/O at the same time as the CPU.

    I see thank you very much for the explanation! I can see how that could be quite enticing for testing and verification purposes of the project. Thankfully, I do have the time to just do the whole upgrade at once! (Assuming all goes well). 

  6. Posted

    Hi, 

    I have a very small offline application I was considering, mostly because of the price tag and wanting to try out an AD PLC, using the C0-10DRE-D PLC. I called AD and asked some questions to make sure it was industrially suited, but I was hoping to get some insight from someone who has maybe used one. My basic questions are have you ever had any issues with maximum input currents into the AD PLC? Like If I am using an inductive proximity sensor that can send out up to 50mA are most of the AD PLC's equipped to handle these values? Do they hold up over time, and has anyone had one installed for a few years to provide any feedback on the good and the bad? 

    Also, I would probably be using a 24 VDC coil to drive a 120VAC pump. I saw on AD website they have some relatively cheap socket relays for the relay and socket combined in the like 8$ range. Anyone have experience with these? The contacts are plenty high enough ratings on voltage and current for my application, just was curious how they hold up, if anyone knows.

    If any of these questions are inappropriate for this forum, I apologize, I am new here!

    Thanks in advance!

  7. Posted

    Thank you everyone for your responses, I appreciate it greatly!!
     

    @BobLFoot I am going to be converting the CPU and I/O all at once, as that was the directive I was give. However, I am very curious about what you are saying. I am rather new to the game, I've learned a few tricks, but much more to learn, and what you said has me a little stumped. Are you saying I could remove the SLC 5/04 CPU, place in an Ethernet card, such as a 1756-ENET, and run the program with the old I/O cards and chassis (i.e. 1746-IA16, etc) over the Control Logix processor? 

    I guess I fully understand how the Processor could be sitting on my desk and connect to the ethernet card over the plant network, but how would the I/O mapping go? On a blank project it wont let me select a CLX processor with a 1746 Chassis. If that's going to be complicated to explain over a forum thread, no problem I will research this on my own, but if you don't mind and it isn't an overly complicated explanation, I am all ears!.... or eyes in this matter.

     

    Again, thanks for the responses everyone!

  8. Posted

    1 hour ago, panic mode said:

    rate is secondary value (it is a first derivative of position) and inherently inaccurate due to low sampling rate and further processing that all have own rate and latencies (signal conversion to analog, transmission, conversion back from analog to digital, integration using goofy logic with timers). 

    why not use HSCE to generate pulse for each foot of travel? why not do everything in one PLC?
    if transmitting values to another PLC, why not use digital signal instead of analog?

     

    They are using HSCE to generate the foot pulses in the first PLC, then they sent an analog signal over as the rate value to the other PLC and attempted to re-construct a foot pulse off the rate value. It didn't help the rate value sent wasn't even properly scaled. I am going to upgrade the SLC 5/04 to a CLX that is getting the analog signal of the rate value and wanted to attempt to get this issue fixed with the controls change. As of right now neither PLC has any communications between the two, and whoever set it up ~15 years ago chose to use analog signals to send the information over. I can of course change whatever I want in the PLC they are letting me upgrade, but as of right now, I cannot touch the other one. They are both SLC 5/04 I believe. As I am unfamiliar with the HSCE2, I only did some reading on it upon encountering this issue, I was curious why if they wanted a foot pulse they sent over an analog rate value as well instead of a digital output of a foot pulse that an input could read and increment an internal counter. But they also wanted a FPM value to scale back to an analog output over Flex IO and send to a display meter on a panel. I plan to eliminate all the display meters and just put the values on an HMI there now, so I guess that portion is irrelevant, except they want both a FPM value and a foot pulse counter. The foot pulse is being used to track faults down the line. I.e. if NDT tester evaluates an error, and the offload of faulted product is 64 feet down, once 64 pulses have occurred they know the faulted item is at the spot to remove it. Being the ineffectiveness of the code, they've always resorted to faulting everything +/- 10 feet from the 'faulted product'. It has been good enough to get ball park range and then do so that way. 

     

    I assume with a PLC upgrade they expect things to work better, so I don't want to upgrade the PLC and leave old issues present. As far as my question of if I could send the counter value over as analog, that makes far less sense than using a digital wire, I just already had analog wiring pulled so I was curious. 

     

    I think after reading what you said and typing my response... my best course of action is to create a digital output from the first PLC when a pulse occurs and run that to an input wire in other PLC. Max line speed is governed at like 120 FPM, so the standard digital I/O should be able to keep up with that just fine and not lose counts I imagine. 

  9. Posted

    16 minutes ago, ElectronGuru said:

    Since you have so many questions, the best thing to do is contact your local Rockwell / Allen Bradley distributor using this link:

    https://locator.rockwellautomation.com/

    They will have a controls specialist who can answer all of your tech questions, and that will be where you purchase your hardware, as well.

    Thank you very much for the prompt response and the link sir, I appreciate it very much!

  10. Posted

    Hello,

    Hoping for a little insight on this Counter Card. I am new to a small company, they've have many 'issues' ongoing for long periods of time that never got solved. One comes from an HSCE2 Card. What they are doing is taking the Rate value off a HSCE2 counter card, and converting it into FPM. They actually had the scale improper, but I fixed that. (They were always showing ~11% faster run rate than actual because improper values in Scale with parameters function). Now that I have fixed that what they did is took that Rate value converted into Feet per minute, then scaled that from 1-32,767 and set it out as a differential analog output, going to the analog input of another PLC. In the other plc, once they re-construct it back to a FPM calculation it gets strange again.

    They take 60 seconds and divide it by the FPM. This makes sense I believe, because say 100 Feet per minute. 60 seconds / 100 feet per minute = 0.6 seconds per foot ran. They then take this 0.6 seconds value that is obviously a constantly updated variable depending on how fast they are running and moving it to a Preset value of a timer. Now they use this timer to generate a 'Pulse' for every foot ran.

    After fixing the Rate value to get the proper FPM, I replicated this conversion to the foot pulse they made, which of course ends up with a x100 because the timer is in Deci-seconds in the SLC 5/04, and something doesn't add up. If I put a 60 second timer after 60 seconds move the count into a holding register to view it, it is always way less than the FPM from the rate value, which has been verified to be correctly monitoring the speed now. I mean, say the timer preset value is 0.7 seconds. 60 seconds / .7 seconds = ~85-86. So after 60 seconds, it wont have counted the counter to 85 or 86, it will be like 80. Is this a scan time issue? I mean logically speaking if I put a .7 value in a timer, and have its own XIO .DN instruction resetting it every time it finishes, as fast as the scan can reset it, and then immediately under that the XIC .DN bit counts up a counter by 1, THEORETICALLY, after 60 seconds I should have my full count, not drastically under. 

    Is this why the HSCE2 card gives a rate value AND a counter, because using one to mathematically construct the other in the processor is an inaccurate process? The counter is hooked up as well on 1024 PPR pulse tach, so on the front end the PLC it goes to has an accurate count. But then they send rate value over analog signal to other PLC , rate value now seems accurate after fixed scales, but the construction of a 'Foot counter' from the rate value is not working properly. Could I send the "count value" over an analog channel as well? Scale the 0-1024 PPR to 1-32,767, then on input side take the 0-10000 mv and scale back to 0-1024? 

    Sorry for the text book!

  11. Posted

    Hi,

    I am looking into upgrading a SLC 5/04 to a ControlLogix processor. I believe I've done sufficient research to know my chassis size and I/O needed. I was wondering where I could get some technical questions answered to be sure. For example, old SLC 5/04 has 1746-NI8. The NI8 has 8 analog channels that can be all 8 differential, or single ended. At first glance the 1756-IF8 is the same, but appears to only support up to (4) differential analog signals, so I need the 1756-IF16? Or, my 1746 RIO scanner communicates to my Flex I/O analog cards through BTW/BTR instructions. If I eliminate the RIO scanner, go to 1794 AENT and use ethernet is the whole BTR/BTW instruction deal eliminated and I can pass the analog value since over the ethernet? Like I just add the RIO to the I/O tree , set the IP address, add the modules, and I can access the data stored in the analog modules that easily? 

     

    These are just a few examples of some technical questions I have. The location I am at is very small, no one to really ask anything to. They are in the process of purchasing Tech Connect, would that be the ideal place to source these sorts of questions? (While I am sure people on this forum could answer questions, if something goes awry and my company says, "Hey, I thought you verified this item?" and I say, "Ya, DogLogver_44 on Mr. PLC forums said it would work!", I may be in trouble.)

     

    Secondly, does Rockwell have local distributors I can call and tell them what items I need, get a formal quote generated, and order from them?