
PouchesInc (Customer) asked a question.
So here is an interesting one for you all. I have a Bartelt horizontal machine I am retrofitting with a P2k and servos. It used to have a single AC motor with a VFD for driving the machine, and a clutch brake with an ElectroCam PLS to control the machine registration. Basically, the motor would run and it will drive a shaft that in turn drives film rollers. These rollers pull the film and when a registration mark is detected, a clutch would engage to keep the shaft from turning anymore during that cycle.
The ElectroCam PLS comes into play here because it has a "registration window" you set the beginning and end of. So the machine will only enable the registration within that encoder count window. You would use this when you are running the machine in a way that it is running two sachets per machine cycle, but the film web is printed as single sachets and so you would basically have two registrations marks per machine cycle and don't want to stop at the "halfway point" when you see the first sachet's mark.
So in the Productivity PLC, I am trying to replicate this functionality, but the move commands only have a way to either use registration or not use registration, no way to make it only active within a certain encoder count range.
My first thought was to check what the accuracy would be if I used a VMOV instead of SMOV and a separate registration instruction. This way I could enable the registration instruction rung only within the encoder counts I wanted. Unfortunately, this proved to be very inaccurate. Producing much more overshoot of the target size than is acceptable, and having quite a bit of variance in the product size from cycle to cycle. My conclusion here is that SMOV is more accurate because it has a motion profile it is doing already, and is already decelerating in the move before it hits the registration mark. The reg mark simply stops the move about 1/64" earlier than it would have already in the motion profile. Using a VMOV, the motion isn't already preparing to stop when it hits that registration mark.
So, on to trying the next idea I had. I thought that I would try running the output of the registration sensor through a solid-state relay before it went into the PLC's high-speed GP input. My thought was that, generally, transistors are pretty fast. I might get something like a 4-8ms delay in the signal by doing this which shouldn't be an issue. So I send the reg. sensor output into the relay's contact side, then send the output of the relay's contact side into the PLC input. I use another discrete output on the PLC to turn the relay on only within a certain encoder count window. In this way, I can effectively block the registration mark signal from getting to the PLC, as it can only go through when the relay is on. This turned out not to work very well though, with only slightly better accuracy than using the VMOV and a registration instruction. I was still getting too much variance between cycles and I was actually overshooting by at least 1/32". So I theorized with doing this, that the solid-state relay must simply be much slower than I thought it would be. On to the next idea.
I have used FC-ISO-C's in the past to both buffer an encoder signal and to change voltage levels and signal types. I knew it was very fast and accurate with high-speed signals, so I thought I would try running the registration sensor signal output through the FC-ISO-C instead of a solid-state relay to improve transistor switching speed. So I wired the FC-ISO-C in place to test if it would indeed improve my accuracy over what the SSR idea did, and sure enough the accuracy was vastly improved. So the issue was the switching speed I was dealing with on the solid-state relay. I was now back down to 1/64" target accuracy I wanted and more importantly, was very repeatable between cycles. So with this, I had reached the same accuracy as simply running the sensor straight into the PLC input.
So now I wanted to see what would happen with the FC-ISO-C if I started turning the device on and off during each cycle. How fast was the "bootup"? Would this work as a way to block my signal during certain parts of the cycle and pass through my signal during others?
So I used the same PLC output I had used to turn on or off the solid state relay to now instead send power to the FC-ISO-C and turn the device on and off. Unfortunately, I found that when the FC-ISO-C is powered off that it will send a voltage on its outputs. So the PLC thinks it is seeing a registration mark at all times when the FC-ISO-C is powered off. This won't work, as now the PLC is false triggering all the time. As soon as the film web starts moving during an SMOV, we reach an encoder count on the cycle where I would turn the ISO-C off, and the SMOV thinks it just saw the registration mark and stops the film.
So that is where I am now; trying to think of a way to block the signal from the registration sensor only during certain parts of the cycle and do it in a way where full accuracy is maintained as if the sensor was running straight into the high-speed GP input. Trying to get the same functionality as the extremely old ElectroCam PLS was able to do.
Does anyone have some thoughts or ideas I could try?
Also, feature request:
Add a checkbox to enable the registration function of an SMOV only when a specific input is true like this:
If anyone has made it this far, thanks for taking the time to read this all. 😅
This is a very interesting problem to solve and I like the way you have gone about it thus far. Multiple registration events per machine cycle is very common in packaging ( as I am sure you know ) and in some controllers I have used in the past allow you to select the number of registration events expected per machine cycle which looks like exactly what you need.
Just to recap my understanding, you are using an SMOV, and registration, then it seems that your machine is an intermittent motion type which means your stopping every other product. Each product has a registration mark that you want to ignore every other mark ( two printed marks per machine cycle ).
Your idea about using the FA-ISO-C is a good one. When you tried it, I am sure you had the (-Ai tied to reference assuming you where using channel A). What if -Ai "floated" every other mark which realistically should prevent the mark event from turning on the Ao output. Use channel B output "floating" to be the reference of channel A. It seems to me that should work but I am not at a place I can test it first before writing this.
Also you mentioned the VMOV which I believe will work equally as well as the SMOV. Judging by your SMOV editor mock-up, you units are revs and your Decel to Stop is set to 0.01 revs. As long as the scaling works out the 0.01 revs is greater than or equal to 10 steps, the VMOV should stop in time. Remember, Decel to Stop is a distance not a deceleration. As a side note: the decel that the instruction calculates based on the current velocity when it is time to stop will not stop in 10 steps if the Maximum deceleration rate defined in the configuration prevents stops that quick.
I really like the idea of having a Enable Registration on Input to address the issue of multiple registration event per cycle.
I hope this helps and id I think anything else, I'll write it down here.
Good luck.