% Feedrate

[caslen]

The system I have inherited uses a % Feedrate control based on the I10 and M5198 variables (only CS1 used). As I understand it if M5198=I10 then we have 100% feedrate, for 10% feedrate we set M5198 to I10/10 etc. This works reasonably well but very occasionally M5198 appears to change by itself! This becomes a real problem when trying to stop the machine in a controlled manner, the previous application engineer decided that to do this he would call a PLC, this PLC calls a "&1 %0" command and then sits and waits for M5198 to reach 0. this can take 1-3 seconds but sometimes takes a minute or more - monitoring M5198 in the watch window shows it counting down towards zero before rising then counting down again - eventually it gets to zero but as this is my machine controlled stop PLC the machine may have trundled off the end of its rails by then!! Are there any system functions that change this variable? Has anyone else had experience of this? Thanks

[Unit101]

Hello, First I5198 is not intended for this purpose - it is the CS Max Feedrate value. It is used when running motion programs to setup a Max value usually by the machine builder so that no user will exceed this rate in his downloaded motion programs. Using it for changing the feedrate WHILE the program is executing will not give you the results you want when you want them. It does not effect ALL motion commands and often when you change this value other motion cmds have already been processed, so you will not see smooth results you want. This parameter is most often set ONCE to limit feedrates and left alone. There are several other ways to control feedrate WHILE a program is executing... -using the % Command is fine and can be changed at any time while running a program -if you want to get a controlled stop in middle of program execution the best approach is to use the "H" command for Hold - this will bring the motion to a controlled stop, you can leave the % command alone, when you want to start again send the "R" run command and machine will accelerate to the currently set % value of Feedrate. This is similar to the %0 command but not the same. -There are other commands and methods to do what you ask, but the "H" command is most often used. -Look in the Turbo Software Reference Manual Page 352 under the "H" Feedhold command for more details and references to other commands that do similar. Let us know if this works for you or need more clarification.

[caslen]

Thanks for the quick response, I5198 is used in two areas, the first as I have already described is to aid in a controlled stop. I will use your suggestion of the 'Hold' command to replace this - one question, if I want the stop to be permanent ie to prevent the restart facility should I issue a CTRL A after the H? The second place in which I5198 is used is in feedrate control while in cycle - I am assuming from what you have said that I would be better off issuing a '%' command to control the feedrate rather than messing with I5198? In the meantime I will look at the hold command in the manual as you suggest - once again thanks for the help. [quote='Unit101' pid='844' dateline='1290176900'] Hello, First I5198 is not intended for this purpose - it is the CS Max Feedrate value. It is used when running motion programs to setup a Max value usually by the machine builder so that no user will exceed this rate in his downloaded motion programs. Using it for changing the feedrate WHILE the program is executing will not give you the results you want when you want them. It does not effect ALL motion commands and often when you change this value other motion cmds have already been processed, so you will not see smooth results you want. This parameter is most often set ONCE to limit feedrates and left alone. There are several other ways to control feedrate WHILE a program is executing... -using the % Command is fine and can be changed at any time while running a program -if you want to get a controlled stop in middle of program execution the best approach is to use the "H" command for Hold - this will bring the motion to a controlled stop, you can leave the % command alone, when you want to start again send the "R" run command and machine will accelerate to the currently set % value of Feedrate. This is similar to the %0 command but not the same. -There are other commands and methods to do what you ask, but the "H" command is most often used. -Look in the Turbo Software Reference Manual Page 352 under the "H" Feedhold command for more details and references to other commands that do similar. Let us know if this works for you or need more clarification. [/quote]

[Unit101]

-Several ways to stop a program - -Abort will work fine - be sure to read in manual how it handles the decel to stop and stop position. -Some may use the "H" to better control decel, then after done issue a Abort command. - Also the Q or quit command can be used.... - all will work and bring it to a stop in bit different ways, I suggest you read about them in manual and pick/setup the one that works best -often the Abort is used for emergency type stopping -Note that a CTRL A - Stops ALL CS programs (even though you only have one... and it ALSO brings any Killed motors to Enabled state in those CS's. --- So a CTRL A does NOT KILL MOTORS... - you could use "H" - wait for motion to stop then "A" to abort the program then "CTRL K" to kill all motors ... just depends on how much you want to abort, stop... kill motors ??? --do not use I5198 to control feedrate... use the feedrate command % instead - if easier in your program you can setup a Mvar in your program and use that to control the feedrate, it is the same as the % command E.G. M5197->X:$2000,0,24,s ;cs1 feedrate M5197= 100*I10/100 //this sets CS1 Feedrate to 100% M5197= 50*I10/100 //this sets CS1 Feedrate to 50% --- this is handy if for example you have a feed pot or user input that they change while running to adjust the feedrate... just a different way to do the same thing...

[caslen]

The nature of the machine is such that it is common for the operators to want to abort the cycle part way through so it is normally not neccessary to kill the motors, I think a 'Hold' and 'Ctrl A' would be sufficient. Some of the machines are quite large and have a lot of inertia and so a sudden stop feels like the thing is shaking itself to pieces hence the original attempt at setting the feedrates and messing with M5198 to try to control the stop a bit better. I think with the hold command all this should be taken care of providing Isx95 is set up properly?

[Unit101]

Yep... Do a Hold to get nice controlled stop, then when stopped Abort. Couple ways to wait for stop, one way is to look at the in position bit of the CS and for this should work fine E.G code could look like this: M5187->Y:$00203F,17,1 ; &1 In-position bit (AND of motors) #define Delay1 i6512 #define msec1 *8388608/I10while(i6512>0)Endw ... in your PLC.... to stop and abort might look like this... cmd"&1H" ;Decel CS1 to Hold Delay1= 1000 msec1 ;wait 1 second while(M5187= 0) ; here while the CS1 is still moving axes to stop Delay1= 1000 msec1 ;wait 1 second each time checking endwhile Delay1= 1000 msec1 ;wait 1 second ;here when CS1 has stopped all the axes cmd"&1A" ;abort the program running in CS1

[Sina.Sattari]

One thing I have seen that the Isx98 doesn't follow the commanded value from % command and customers claim that it does something that they can't explain, was caused by PEWIN32PRO and PEWIN32PRO2 Jog Ribbon tool. The way that this tool is implemented, it can't tolerate any change in feed rate override from outside the Jog Ribbon and it would cause problems. Make sure that the Jog Ribbon is closed and try the test again.

[caslen]

Sina, I've done some checks with feedrate and the jog ribbon but I don't see any correlation with the problem I have - sometimes it happens sometimes it doesn't, whether or not the jog ribbon is open or not. Unit101, I appear to be running successfully with "&1 H" followed by "Ctrl A" you suggested that I monitor M5187 after the "&1 H" command to ensure the motors have stopped. I'm a little nervous doing this since any 'while' loop of this nature is potentially non-terminating. Under what circumstances would "&1 H" not stop the axes after, say, a couple of seconds? Or is it that it is just a catch all for any very slowly deccelerating axes? Cheers Steve [quote='Sina' pid='849' dateline='1290191241'] One thing I have seen that the Isx98 doesn't follow the commanded value from % command and customers claim that it does something that they can't explain, was caused by PEWIN32PRO and PEWIN32PRO2 Jog Ribbon tool. The way that this tool is implemented, it can't tolerate any change in feed rate override from outside the Jog Ribbon and it would cause problems. Make sure that the Jog Ribbon is closed and try the test again. [/quote]

[Unit101]

Yes I agree 110% that need to use caution with blocking logic like a while loop. I did not show more code that I would normally have for timeout. I don't like using just timers to wait a few seconds... this is quick and dirty code fine for testing but in real production can be very costly wasting time every time or not working well because time is too short. Much better to work with real events such as monitor the CS In position then use time. However need to prevent it from blocking so I would add some logic to timeout in case of problem. I like to dedicate one timeout counter to each plc, since each plc could have only one while loop at a time blocking... so I do it like this... #define plc6_counter P41 plc6_counter = 1 while(M5187 = 0 AND plc6_counter < 50 AND fault = 0) ;here inside the while loop Delay1 = 1000 msec1 ;wait for 1 second endwhile plc6_counter = 0 NOW in a different PLC - that I only use for Timers/Counters... this PLC is never blocked by while loops. It is used to increment counters every so often... so they can be used as above. In this PLC I would increment the plc6_counter by 1 every 10th of second IF it is greater than 0. So by setting to 1 - activates it and the timer plc will increment by 1 every 10th of second. So the above while loop would exit with timeout after waiting about 5 seconds at the most... after exiting you can look at the counter and determine if it timed out or all is cool and act accordingly. There are for sure many other ways to do this... but this is my basic project logic used in all my programs. I be glad to send you more example code of the timer plc if you need.

[caslen]

I'll try this out tomorrow, I have another problem at the moment that I'm trying to sort out - a motion program that won't run at the correct speed! The program is very simple:- OPEN PROG 10 CLEAR LINEAR FRAX(X) F(P1000) TA500 TS100 X(P1001) DWELL0 CLOSE I set the speed in P1000 and the target position in P1001 but when I run it the velocity increases well past the maximum until it faults out with a following error. My feedrate limits are set as far as I know to sensible limits. The X axis is defined as a kinematic axis using FORWARD and INVERSE but is not 'connected' to any other axis - it is a basic linear axis. Any ideas? Are there any other speeds or limits to set in this case? regards [quote='Unit101' pid='851' dateline='1290441963'] Yes I agree 110% that need to use caution with blocking logic like a while loop. I did not show more code that I would normally have for timeout. I don't like using just timers to wait a few seconds... this is quick and dirty code fine for testing but in real production can be very costly wasting time every time or not working well because time is too short. Much better to work with real events such as monitor the CS In position then use time. However need to prevent it from blocking so I would add some logic to timeout in case of problem. I like to dedicate one timeout counter to each plc, since each plc could have only one while loop at a time blocking... so I do it like this... #define plc6_counter P41 plc6_counter = 1 while(M5187 = 0 AND plc6_counter < 50 AND fault = 0) ;here inside the while loop Delay1 = 1000 msec1 ;wait for 1 second endwhile plc6_counter = 0 NOW in a different PLC - that I only use for Timers/Counters... this PLC is never blocked by while loops. It is used to increment counters every so often... so they can be used as above. In this PLC I would increment the plc6_counter by 1 every 10th of second IF it is greater than 0. So by setting to 1 - activates it and the timer plc will increment by 1 every 10th of second. So the above while loop would exit with timeout after waiting about 5 seconds at the most... after exiting you can look at the counter and determine if it timed out or all is cool and act accordingly. There are for sure many other ways to do this... but this is my basic project logic used in all my programs. I be glad to send you more example code of the timer plc if you need. [/quote]

[Unit101]

What is your axis scale factor for the CS ? #1->????X What is the timebase for your CS ? I5190 = 1000 = seconds Remember your Feedrate command is going to be the scale factor * counts / timebase units. So if you have a scale factor of 10 and time base of seconds a feedrate of 100 = 1000 counts / second Try setting your Feedrate command to a very low value and see if it works. Try setting your I5198 to low value and see if it works. Also look carefully at the Kinematic Subroutines, in here the scale factors could also be mis-applied and giving you some big value that the motor cannot achieve. In fact to prove it is not in Kinematic, turn this off and just run it as a normal motor. If it works then issue is in your Kinematic routines.

[caslen]

Scale factor is set by the kinematics I think hence I have :- #1->I in the coordinate system. I5190=1000 I5198=1 (already set low) I have already run this as a regular motor and it works fine - so by your last statement it must be the kinematics, they are very simple:- &1 Open FORWARD Clear Q4=P1003 Q5=P1003 Q6=P32 Q1=0 Q2=P4/10.0 Q3=0 Q7=P1/1000.0 Q8=P2/10.0+Q4*cos(Q2) Q9=P3/10.0+Q4*sin(Q2) CLOSE &1 Open INVERSE Clear P17=Q4*(P1003) P18=Q5*(P1003) P4=Q2*10.0 P14=P2 P1=Q7*1000.0 P2=(Q8-Q4*cos(Q2))*10.0 P3=(Q9-Q4*sin(Q2))*10.0 P32=Q6 CLOSE I have checked that the scalings match - maybe I missed something so I'll check again, its finishing time here so it will have to be tomorrow, thanks for the help, [quote='Unit101' pid='853' dateline='1290446659'] What is your axis scale factor for the CS ? #1->????X What is the timebase for your CS ? I5190 = 1000 = seconds Remember your Feedrate command is going to be the scale factor * counts / timebase units. So if you have a scale factor of 10 and time base of seconds a feedrate of 100 = 1000 counts / second Try setting your Feedrate command to a very low value and see if it works. Try setting your I5198 to low value and see if it works. Also look carefully at the Kinematic Subroutines, in here the scale factors could also be mis-applied and giving you some big value that the motor cannot achieve. In fact to prove it is not in Kinematic, turn this off and just run it as a normal motor. If it works then issue is in your Kinematic routines. [/quote]

[Unit101]

Hi Steve, I apologize for the hassle but this thread has become a mess. And it was pointed out to me that I got it all started by mis-reading your original question - you said M5198 and I Saw I5198, both related to your feedrate issues but not the same. And now we have got the issue on another tangent with Kinematics and your motor Feedrate being too high. I think this thread will be killed and removed since it now just serves to confuse anyone that reads it. Please send me a email directly or call and we can pick up and get back on track. Or if you wish just post another question on the forum and we can start over. Thanks, mike mesposito@deltatau.com 919.435.1159 12/1/10 update - Steve and I worked on this issue with TeamViewer and resolved the problems - main problem was that I5113=0 and must be >0 for Kinematics.