It would be nice to have the status of the conveyor when activated by the PLC, because it can be made dysfunctional / bypassed by FactoryTalk IO. The state can be run, forward, reverse or actual speed for the analog conveyor. This allows the PLC to detect the problem, but also if necessary, to interlock it
1 Like
Hi Patrick,
You can use sensors to detect if parts on the conveyor are moving.
You can also check the encoder feedback on the conveyor to get the speed info.
Not quite like having a conveyor system status but still a good feedback.
From which school are you ?
Frédérique
You understood, it is not like the auxiliary contact of a contactor (FactoryTalk IO Conveyor Feedback). Thank you for your recommendation.
For the school, it is Cegep de Jonquière, Quebec, Canada.
Patrick
Hi Patrick,
I did my PhD at Poly Montreal, so we were almost neighbors!
The conveyors have very small indicators on the rollers that show if they are moving, but it would be very nice if those indicators were more obvious. I think, however that you want an indicator to show the dirction the conveyor will move once it receives a signal? That does not exist.
Paul
The Idea is to get the status of the conveyor on an input of the PLC. Like a contactor that activated by PLC (Motor on screen), get the motor status (contactor auxiliary contact) at a PLC input.
This is because FactoryTalk IO software can interfere motor (contactor) and the feedback signal (contactor auxiliary contact) (Force On, Force Off). It’s not just a question of the image on the screen… we talk more about interlock, and status.
Thank you for your suggestions.
I’m not sure if I understood correctly.
You want a feedback from the conveyor that it is actually turning when your output tells it, that it should turn?
I have not yet seen such a feedback for a normal conveyor in real life, this would normally be done by some kind of timeout that would trigger if a sensor isn’t blocked within a certain time.
If you really need a feedback, you can enable the encoder on the conveyors. The encoder is simulated as a wave-encoder, outputting 2 waves that are 90° out of phase. The signal is outputted as 2 Bits, A and B, and by analysing the signal you can get a feedback of a) that the conveyor is moving, b) how fast it is moving and c) in what direction it is moving.
a) if A and B change their signal the conveyor is moving
b) if I understand the documentation correctly you will have 20 full wavelengths per second for the default movement speed of 0.45m/s for the conveyors.
c) the default order for forward movement is: ((A0,B0), (A0,B1), (A1,B1), (A1,B0)), so if you see signal A before signal B, the conveyor is moving forward, and if you see Signal B before Signal A, the conveyor is moving backward.
See the Encoder documentation for more details.
Yes, it is possible to use the encoder. But is much more complex than if the software gives us the status of the conveyor (Running) Do not forget that the software can force the conveyor (Force Off (like no power on CCM), Force On (like stuck contactor), or normal).
Same for (Running forward running reverse,) (Drive ±speed), if applicable
This is a suggestion for improving the software. Thank you all.
While I do see where you’re coming from, this is as said not really what someone would encounter in reality.
I do not agree.
It is normal to supervise the contactor/motor when the PLC engages it. This is standard in heavy industrial applications that I have seen. It is not assumed that the contactor/motor has engaged without feedback. It is a question of doing the same principle in the simulator, which is currently not possible. Here is my suggestion for improving the Factory IO software.
Thank you all for the answers. It was interesting.
Aaah, I see. There lies the misunderstanding.
My assumption was that you hinted at there being a real life boolean signal that signals if the motor is actually turning, not just that it SHOULD be turning based on the commands given or contacts closed.
On the suggestion you are making I would like to point out that factory IO doesn’t have any electrical feedback on any level, safety buttons/sensors are single channel and there is no kind of electrical contactor that could be switched to cut power to conveyors.
Indeed, there is no electrical feedback, except for the status of the software itself (Paused, Reset, Running, Time Scale). It is not forbidden to improve the software, especially since it is easy to add.
I ask a question from another angle, how can the PLC know that the conveyor is in error (Failure injected / Force On, injected Off Failure / Force Off)? Please, leave aside the encoder.
I haven’t looked at all the components, but for a conveyor/motor I think it’s necessary.
Patrick Bouchard
Of course, improvement is fundamental.
The failure of a non-running conveyor is normally tested by starting a timeout-timer when a part is being sent from one conveyor to the other. If the part has not arrived on the second conveyor in time, the timeout error is raised.
A failure of a constantly running conveyor is tested by checking a sensor that shall not be activated before a controlled transport has been started. This is normally primarly relevant for moving parts that could thus be blocked and crash. If such a sensor is activated before a transport has been started, an error is raised.
What you propose is to deduce “by the band” if the conveyor is in operation or not. That’s one way of looking at it, but it’s not my design philosophy. Always go for the simplest.
If the simulator dictates how to build the line, I can’t say anything. But in real life, I wouldn’t make the line this way.
Know that I respect your point of view. Thanks for sharing.
It’s curious how the designs are different between Europe and North America.
1 Like
You can use one pulse off the encoder as a zero speed detector as the best option and this does simulate what we used to do in the field. Zero speed detection not only verifies electrical but also mechanical operation as well. Since there are no contactors in the simulation, it is not practical to test for feedback or overload conditions and would therefore be beyond the scope of the software. The fault detection theory wouldn’t be too far off the mark from a training perspective IMHO.
1 Like
Drop the idea from the encoder. If you have 100 conveyors, are you going to take 100 encoders to validate the operation of a motor? Would you really do that in real life? I use an encoder to follow a part which it moves with conveyor and to locate its position, not to know if a conveyor works or not.
Feedback is very easy to do in FactoryTalkIO software. The conveyor turns in the simulation, we see it in the display, returns the signal to the PLC (see previous image as an example). This is a software improvement recommendation.
Maybe I am explaining myself badly, but sincerely, it is about basic concept. Final post on the subject.
Thank you.
1 Like
An encoder would indeed be a more expensive and complicated option on a real physical system. Typically we used a proximity switch that would pulse for each revolution of the final drive assembly and each conveyer would be assessed if the risk is worth the extra detection costs. In a lower risk setting, we would use general timeout faults tied to monitoring part movement from one location to another utilizing existing part present sensors. In the simulation, part movement detection is possible, however, since there is no option to add a simple rotational detection mechanism, the encoder pulse would be good alternative.
1 Like
Okay, so it wasn’t just me that thought maybe a motion detection on every single conveyor would be a tad overkill.
We basically use the same system as you guys from the US it seems. Risk analysis, and add a detection where rotor confirmation is important (for example where if the motor turned into the wrong direction or for too long or not at all it could have a bad outcome). That would normally be the case for any motors on vertical axis or in general if load could drop from somewhere down on someone. If we have something like a stacker crane or transfer carriage, we normally have multiple “gap control” sensors that check if a load is sticking out into the movement area.
Hell, for the last project we had to nearly fight for every additional sensor with our partner because of cost related reasons.
1 Like