mholland79

Well after some head scratching, deep thought, and all of your thoughts, this is where I am at. Everything is Polled still and scanned in the foreground, as it always was. Increased interscan delay from 10ms to 20ms. No devicenet problems in 5 days!!! Thanks again. That is a great explanation. Why couldn't my AB Engineering rep explain it that way.......

Just looking for an opinion. Here is what I have: AB 1769-SDN - Scanner is Master for 17 nodes using a byte of I/O each mapped in as polled. Each has photoeyes, proxes, solenoids, and pb's connected. Nothing high speed reliant. - Scanner is a slave to a robot with 64 bytes of I/O mapped in as polled. The robot must be Polled but what about the I/O modules? A co-worker (my boss..... ) mapped all of the I/O modules in as polled and swears by it. The issue I am having is that the robot is giving me dnet errors occasionally, like the network is too slow or something. Everything I have ever been taught and used with devicenet is this. Change of State for all I/O except for maybe a high speed counter or something. Something that could potentially communicate larger changes in I/O, like the robot when I give it a part number of 2012 for example in binary. Larger networks that are polled are slow correct? Any suggestions are appreciated. Thanks!!

Greetings Daniel, New member here and was reading some posts and this one caught my eye. Just wanted to throw a few suggestions at you. Not sure how relevant they are to your field but here ya go. I like to have one routine specifically for on and off delay of photoeyes turning one single bit on. I usually start with say PE100 as my photoeye tag/alias and name my timers (TON) T100A and T100B. Why over complicate things with long tags. Then all that is needed for each program is to change your TAG aliases and uplaod. Same goes for VFD/motor control. Keep it all in one routine with only the necessary things in there, start, stop, speed changes, etc. Plus for later debug when a motor isn't going when it should be, it's an easy place to start from. Do all of the detailed control somewhere else that leads back to this routine. A lot of what I do is based on my experience figuring out other peoples logic, I try to make it as uncomplicated as possible without compromising, as Bob correctly stated, scan times. Perfect example is when I am looking at a program that has a rung like: XIC XIO XIC XIO TON XIC XIC OTL OTL OTU all on the same line, that is not logical to me. Yes it works but it visually looks cluttered. TON's and their done bits on the same line seems sloppy to me. Writing ladder logic to look similar to what electrical schematics look like has always made sense to me, besides, it will make sense for that 3rd shift maintenance guy with just enough PLC knowledge to be dangerous but understands electrical controls very well. I hate 2am phone calls that end in him cleaning off a reflector. As far as using Excel, read up on the Concatenate feature. Can't indulge any further but if you figure it our you will love it. Cheers!!