bake time verification

Keep it simple.

I would start over. Set the drive to 25hz and time the cycle, then to 50hz and time again.

Write your new formula from these values.
 
Keep it simple.

I would start over. Set the drive to 25hz and time the cycle, then to 50hz and time again.

Write your new formula from these values.




In the OP it is stated that there have already been measurments, but we don't have those data here.


Pulling teeth ...
 
We also don't know how the VFD is configured (V/f; sensorless/self-sensing vector; closed loop). I am no expert on motors by a long shot, but doesn't at least one of those have the possibility of slip?
 
Standard squirrel cage motors would not produce torque without slip, though the slip percentage shouldn't change from full speed to low but it's impact will be greater. For example, if motor has 5% slip, it's a lot less rpms lost at full Hz than at lower Hz relative to the speed. Previous poster mentioned (rightly so) the possibility of it being a DC motor with battery backup, or the DC motor is a standalone backup, unclear. More likely the second scenario, so probably safe to ignore this.

Too many chefs in this kitchen! I feel the pain of no tag descriptions, it is incredibly hard to figure out what is going on.
 
Last edited:
I timed the oven last night. I set it to 9min the vfd went to 49 hz but the oven took 8.25 min/sec to make it's revolution.
 
I timed the oven last night. I set it to 9min the vfd went to 49 hz but the oven took 8.25 min/sec to make it's revolution.

So now you have one point in your scaling math. You need two points as far apart as possible for best results, then you can rewrite the math to scale the time setpoint more accurately.

49Hz = 8.25 minutes.
60Hz = ???
 
Would it be possible to add something to measure the progress of the product through the oven? So if you knew the product had traveled X percent of the way through in Y percent of the allotted time, you could speed up or slow down the motor to compensate.
 
So the original CPT formula (60/7.08)*(40/target_time)*(32767/100), which is the same as approximately (111075/target_time)* sent 12342 to the VFD, which is 38% of 32767 (signed 16-bit full scale), suggesting full scale (32767 sent to VFD) would be 49Hz/.38 = 130Hz.



If conveyor speed is linear with output, and that may or may not be true, change 7.08 to 7.72.



but first answer what @OkiePC asks, which will tell us if the assumption above is true.




* I would not mess with an uncommented CPT statement. I would instead use [DIV 111075 CurrentRecipe.Bake_Time VFS_setpoint] and put a comment over it that explains where the 111075 comes from.
 
Last edited:
Would it be possible to add something to measure the progress of the product through the oven? So if you knew the product had traveled X percent of the way through in Y percent of the allotted time, you could speed up or slow down the motor to compensate.

Another thought - have a single tray or rack trip a sensor going in (flag on rack going through fork photoeye so heat doesn't effect it)

Time how long that rack is in the oven and set bits if too short or too long time.

As you want pop up warnings on the HMI or autocalculate and change the speed to where it should be.
 
The thing I'm unsure about is, if this is a new problem or an original problem. Because i get different stories from production/management. But back to the problem the only changes that could affect the bake time in the outside world would be motor/gearing changes from original setup. Which could have only be the gearmotor setup the oven was rebuilt 6-7 years ago and the gearmotor was changed . The other change would be on the vfd min/max (0-32767). I'm going to look at min/max setting on the vfd if that doesn't correct the issue , modify the 7.08 in the CPT.
 
You are over thinking it, whatever gearbox changes etc have occurred in the past doesn't matter, you just have to deal with what you have got right now.

Just time the runs at 2 different frequencies and write a new formula to achieve them. Forget all the fog about slip, it's 20 minutes work at tops.
 
You are over thinking it, whatever gearbox changes etc have occurred in the past doesn't matter, you just have to deal with what you have got right now.

Just time the runs at 2 different frequencies and write a new formula to achieve them. Forget all the fog about slip, it's 20 minutes work at tops.


exactly.
 

Similar Topics

A cry for help to parky and Mitsubishi gurus. How do you confirm the firmware version of the iQR PLC or a module such as the RJ71GN11-T2? I have...
Replies
3
Views
1,034
Studio 5000 - strange error , "conflict exists in project verification state" I am trying to upload a test project to our 5069 controller we use...
Replies
7
Views
4,643
Hello, Is there any way of knowing if the battery is depleted in an Allen-Bradley 1756-L82ES in the PLC program? Something similar to the Low...
Replies
1
Views
1,518
Hello: Does any body have experience with tools to simulate DoS attacks, especially attacks which can exploit typical vulnerabilities of...
Replies
7
Views
2,842
Hello: By Beckhoff PLC was working property. It is Windows 7 embedded IPC and has onlt the TwinCAT runtime software. In the firewall of both the...
Replies
0
Views
2,379
Back
Top Bottom