Messed up program access

Moderators: TomKerekes, dynomotion

Scott Pancheau
Posts: 26
Joined: Sat Dec 28, 2019 10:52 pm

Re: Messed up program access

Post by Scott Pancheau » Fri Jan 03, 2020 3:41 pm

I changed the .c as per your instruction. The KMotion will now initialize - Yes! I think I am back to where I was before deleting and reloading the Mach and the 435B. I need to try simulated use a little more to try and figure out what is screwing up the spindle. What I know this far is that if I initialize and then only use the command line at the bottom of the screen (in KMotion CNC) to turn the spindle on and off it does what it should. I can then use the slider and the on clockwise or CCW . The spindle speed displays correctly for RPM and any changes on slider take effect. When I try to run a g code program it is some how messing up the correct correlation of spindle speed and RPM readings. It might run correctly one time and then if you change the spindle speed call with Mo3 it will run at some arbitrary speed and RPM display is way low. If I call for constant surface speed with G96 the RPM will vary as it should with respect to set speed, but sometime speeds up when moving away from X center instead of slow down. Is there any specific sub programs I can take a shot of that you might suspect now has an error in the code? Thanks again for all your help Tom.
Scott

User avatar
TomKerekes
Posts: 985
Joined: Mon Dec 04, 2017 1:49 am

Re: Messed up program access

Post by TomKerekes » Fri Jan 03, 2020 9:17 pm

Hi Scott,

Try setting the Actions for M3, M4, M5, S to "Exec/Wait" instead of "Execute Prog"

Otherwise it might be some mixup in which Variable the speed is being sent and what the Programs are expecting. Please post (attach) all .c and .h files from your CNCLathe folder. Also screens shots of how all the Actions are configured (KMotionCNC Tool Setup Screens).

HTH
Regards,

Tom Kerekes
Dynomotion, Inc.

Scott Pancheau
Posts: 26
Joined: Sat Dec 28, 2019 10:52 pm

Re: Messed up program access

Post by Scott Pancheau » Sat Jan 04, 2020 5:55 pm

Hi Tom,
I tried changing the actions to the "Exec/Wait" settings and KMotionCNC did not seem to like that so I changed it back. What I learned after running the lathe with G code programs is that it seems to run as it should dependably until I add the G96 to the program. I think that is introducing some kind of error into KFlop. Even if I take it back out of the code the spindle will not work correctly until I close out and reopen KMotion. Then as long as I do not try using CSS all seems to be good. I have included the shots of tool settings and I think, the requested files. I included 10 attachments with this and will post again with another 5.
Thank you Tom
Scott
Attachments
OnCWJog.c
(1.17 KiB) Downloaded 27 times
OnCCWJog.c
(1.13 KiB) Downloaded 25 times
OffJog.c
(497 Bytes) Downloaded 21 times
MySpindleDefs.h
(645 Bytes) Downloaded 29 times
CSSJog.c
(1.95 KiB) Downloaded 31 times
CNCLathe.c
(4 KiB) Downloaded 28 times
Tool set up for Basic 2 Axis 1-4-20.PNG
Tool set up for user buttons 1-4-20.PNG
Toolset up for M3 M4 M5 CSS 1-4-20.PNG
Trajectory planner as of 1-4-20.PNG

Scott Pancheau
Posts: 26
Joined: Sat Dec 28, 2019 10:52 pm

Re: Messed up program access

Post by Scott Pancheau » Sat Jan 04, 2020 6:16 pm

Here are the other attachments with program settings.
Thanks,
Scott
Attachments
SpindleMach3Jog.c
(1.27 KiB) Downloaded 26 times
SimpleHomeIndexFunction.c
(2.11 KiB) Downloaded 22 times
HomeMachLathe.c
(1.6 KiB) Downloaded 25 times
HomeLathe.c
(1.33 KiB) Downloaded 19 times
SpindleJog.c
(1020 Bytes) Downloaded 26 times

User avatar
TomKerekes
Posts: 985
Joined: Mon Dec 04, 2017 1:49 am

Re: Messed up program access

Post by TomKerekes » Sat Jan 04, 2020 7:31 pm

Hi Scott,

Thanks for all the info. I don't see anything wrong.

You might try changing X Positive Front option in the Trajectory Planner Settings.

What I learned after running the lathe with G code programs is that it seems to run as it should dependably until I add the G96 to the program.
G96 turns on CSS. You might turn off CSS with G97 and check if it then again works properly without CSS.

Do you realize that with CSS the rpm varies with radius? Please make a simple example in KMotionCNC to turn on CSS, set an S value, Move X to some radius ie. 1 inch, post the GCode, what the DROs read, and what happens.
Regards,

Tom Kerekes
Dynomotion, Inc.

Scott Pancheau
Posts: 26
Joined: Sat Dec 28, 2019 10:52 pm

Re: Messed up program access

Post by Scott Pancheau » Mon Jan 06, 2020 2:36 pm

Hi Tom,
I tried the reverse of X in trajectory and that just made X move the wrong way. I was not able to try the test you prescribed because as soon as the G96 code is activated the spindle just goes to maximum speed and faults out on drive.I checked the analog output and it was at 9.96 v. I tied to get Mach 3 running to see what it would do with the code. I think the spindle speed user program you had set up was SpindleMach3Jog.c. I can get that to initialize Mach, but something is not right there. The spindle runs at 7% of whatever speed I enter in the MDI line or the program and I think the moves for X and Z are doing the same. I made sure settings are for Inch but the programs run at a small percentage of what the moves should be in inch mode. Is that the correct Spindle speed user program for Mach? That should be thread 2. Should the Home and Notify programs be on thread 2 also or do they need their own thread?

Thanks,
Scott

User avatar
TomKerekes
Posts: 985
Joined: Mon Dec 04, 2017 1:49 am

Re: Messed up program access

Post by TomKerekes » Mon Jan 06, 2020 5:35 pm

Hi Scott,
I tried the reverse of X in trajectory and that just made X move the wrong way.
ok

I was not able to try the test you prescribed because as soon as the G96 code is activated the spindle just goes to maximum speed and faults out on drive.
Please perform the test anyway. It doesn't matter that it faults out. I just want to understand exactly what you are doing and what happens.

To help diagnose what is wrong make the CSS update time longer and enable the diagnostic print out. Report what is printed on the Console Screen after G96 is commanded. In CSSJog.c change:
#define CSS_UPDATE_DT 0.05

to:
#define CSS_UPDATE_DT 2.0

and remove the '//' from this line:
// printf("xoff=%f radius= %f xfactor=%f s=%f(ips) maxrpm=%f rpm=%f\n",*css_xoff,radius,*css_xfactor,*css_s,*css_max_rpm,rpm);


Regarding Mach3 let's work on one thing at a time. But seems like for x or y the steps per unit or units are not set properly.

Regarding Threads: a Thread can only run one program at a time. It is not normal to home and change spindle speed at the same time so they can use the same Thread, but to be safe you might use separate threads as you have plenty available.
Regards,

Tom Kerekes
Dynomotion, Inc.

Scott Pancheau
Posts: 26
Joined: Sat Dec 28, 2019 10:52 pm

Re: Messed up program access

Post by Scott Pancheau » Tue Jan 07, 2020 3:00 pm

Hi Tom,Here is my attempt to provide what you need to see. This G code just sets zero and then advances in X from the start point. If you need me to run a different sort of program I can. Thanks for clarifying the threads question. I was not able to catch the KMotion screen before spindle faulted out, so that is a still shot of the program ran.
Thank you Tom,
Scott
Attachments
Capture Console readout for G96 problem 1-8-20.PNG
Capture Program run to show G96 problem 1-8-20.PNG

User avatar
TomKerekes
Posts: 985
Joined: Mon Dec 04, 2017 1:49 am

Re: Messed up program access

Post by TomKerekes » Tue Jan 07, 2020 6:09 pm

Hi Scott,

Ok it is now clear what is going on. Because the test starts out with a radius of zero the RPM should be infinity. Since infinity is not possible the maximum RPM should be used. But there isn't any max RPM specified in the GCode. In this case the default maximum of 1 billion RPM is used. Obviously the system can't do 1 billion RPM and soon faults.

Specify the max RPM with a D word like in the example here.
G96 M3 D2500 S159.6 (CSS should be 1000RPM at R=25.4mm)

I suppose we should change the C Program so that if the Operator forgets to specify the maximum some better limit is used. You might add a line of code in CSSJog.c to add an additional limit check. Change:

if (rpm > *css_max_rpm) rpm = *css_max_rpm;

to:
if (rpm > *css_max_rpm) rpm = *css_max_rpm;
if (rpm > XXXX) rpm = XXXX;

where XXXX is the max possible RPM you ever want for your system.

Another option would be to display an error message for a max RPM over some limit.
Regards,

Tom Kerekes
Dynomotion, Inc.

Scott Pancheau
Posts: 26
Joined: Sat Dec 28, 2019 10:52 pm

Re: Messed up program access

Post by Scott Pancheau » Wed Jan 08, 2020 12:19 pm

Hi Tom,
Thank you for your wisdom again. I changed the C program as per your instructions and that fixed the spindle faulting problem. I feel like it is really close to 100% again now. I changed the G code program to move to start at X 0 and then move to a 1" radius. If I understand correctly that should invoke the CSS. I have included a shot of the G code and the console print. Once in a while the CSS is applied correctly and the spindle speed changes as it should. The red speed change indicator acts correctly all the time. When the X axis is moving in toward center it shows the speed increasing and visa versa. Most of the time the speed never actually changes and the analog screen shows the DAC output for the spindle as a steady voltage. There seems to be an arbitrary disconnect between the command and the function at KFLOP. Does this bring anything to mind that I should check?
Thanks,
Scott
Attachments
Capture 1-8-20 Console.PNG
Capture 1-8-20  V Groove program.PNG

Post Reply