Dynomotion Forum

Posted: **Mon Dec 28, 2020 5:58 am**

Hi Tom,

I'm currently trying to become familiar with the C Program scenario but am having some issues. Please see the attached screenshot.

I'm running the SimpleHomeIndexFunctionTest in KMotion. It is as original except for a few minor changes I have made:-
1. Remmed out the X & Y sections so I only have to deal with one axis at a time
2. Reduced the axis travel speed
3. Changed the Limit Switch Bit to watch for

When I operate the Save, Compile, Download and Run button (or the separate ones - it makes no difference), the program seems to compile without issues and proceeds to run. This is evidenced by the tick appearing in the Enable tick box and the Destination display counting in the Axis window.

The first issue I'm having is that the Halt button does not stop the program. The only (nice) way I've found to do that is to click on the ticked Enable box. This removes the tick and the Dest display stops counting, so I presume that is stopping it?

The second issue is that the drive is not actually enabled (presumably since I have yet to discover where to tell the system which Bit is the drive enable output), and consequently the motor does not move.

The drive enable Bit is 145 and so I can switch it on using the Dig I/O window. However, doing this doesn't change any of the above - the program still does not drive the motor. Once this is on, I can happily control the motor using Console commands (see screenshot) as expected.

Any clues as to what I am missing in all of this will be greatly appreciated.

Thanks very much,
Peter

Posted: **Mon Dec 28, 2020 1:57 pm**

hatcat wrote: ↑
Mon Dec 28, 2020 5:58 am
The first issue I'm having is that the Halt button does not stop the program. The only (nice) way I've found to do that is to click on the ticked Enable box. This removes the tick and the Dest display stops counting, so I presume that is stopping it?

The halt button only stops that program thread from running. It does nothing else. As the homing program has already issued a Move command, that move command will continue to run after the thread has been killed.
By removing the channel enable box, you stop that axis.

The second issue is that the drive is not actually enabled (presumably since I have yet to discover where to tell the system which Bit is the drive enable output), and consequently the motor does not move.

This is where you need to create what is commonly referred to as your own init.c program. You can call it what ever you want, but for simplicity I simply refer to it as an init.c file, as it is the file that will initialise your machine.

The drive enable Bit is 145 and so I can switch it on using the Dig I/O window. However, doing this doesn't change any of the above - the program still does not drive the motor. Once this is on, I can happily control the motor using Console commands (see screenshot) as expected.

That sounds a bit strange. If the axis destination is increasing, then the motor should be moving.

Regarding the init.c, this wiki page mentions what should be included - https://www.dynomotion.com/wiki/index.p ... C_Programs but doesn't really give much more information beyond that.
There is a basic example init.c files included - InitStepDir3Axis.c

I've attached all the files from my Triac milling machine, which although looks quite complicated, is the best example I currently have.

First off, I define all my inputs/outputs/variables in Triac.h
A couple reasons for this, is it makes writing code easier as I'm referencing names and not numbers, and if I need to change anything (i.e. physically move an input/output) I only need to do a single code change.

TriacInit.c is what does the initialisation. My comments in the file should explain the process (set channel values, check drivers are not in fault attempting reset if needed, enables axes, defines motion system, before reaching the forever loop that handles monitoring the machine.
That loop isn't that well commented, so here it is with a few extra comments added-

Code: Select all

for(;;)	// loop forever
	{
		if(*CrslPos != lastCrslPos){
			printf("Carousel Position changed - %d\n",*CrslPos);
			lastCrslPos = *CrslPos;
		}
		estop_test();		// runs code contained in TriacEStop.c that monitors for EStop conditions, and if any met, handles stopping the machine
		ServiceToolChange();	// Unless you want to run a complex toolchanger ignore this. This runs the code in TriacTC.c
		WaitNextTimeSlice();	// Only needed if you have code you don't want split over multiple thread splices (Tom will explain if needed)
		ServiceMPG();		// runs code in MPGServiceSmoothHardwareEncFiltered.c to handle the mechanical MPG
		// Start of softlimit checks	// code for all these is in AdjustSoftLimits.c, but essentially provides a controlled stop when moving towards softlimits
		if(softLimitCheck == 0){
			CheckDistToStop(ch0);
			softLimitCheck++;
		} else if (softLimitCheck == 1){
			CheckDistToStop(ch1);
			softLimitCheck++;
		} else if (softLimitCheck == 2){
			CheckDistToStop(ch2);
			softLimitCheck = 0;
		}
		// End softlimit checks
		ServiceTower();	// handle our light tower. Code is in TriacControlPanel.c
		ServiceButtons();	// handles the buttons on the control panel. Again in TriacControlPanel.c,
		ServicePots();		// Handles the FRO/SSO potentiometers. In TriacControlPanel.c
	}

Tom, would it worth creating a barebones Init.c example file?

Posted: **Mon Dec 28, 2020 3:34 pm**

Hi Peter,

I think the main issue is you haven't configured (or tuned) KFLOP for the type of Analog System you have. By default KFLOP is configured as Step/Direction so if you command a move it won't work. Commanding a DAC output directly isn't really moving the axis. But it does prove your DAC is wired to the amplifier correctly.

Changing settings on the KMotion Screens doesn't affect KFLOP unless you either download the Screens to KFLOP or convert the screens to a C Program and the execute the Program. You might read this.

The first issue I'm having is that the Halt button does not stop the program. The only (nice) way I've found to do that is to click on the ticked Enable box. This removes the tick and the Dest display stops counting, so I presume that is stopping it?

As Moray explained Halting a C Program only stops the C Program it doesn't stop any motion that may have been commanded.

Disabling the axis will cause an abrupt uncontrolled stop. A better way is to command the axis to stop by telling it to go to zero speed with Jogx=0 command.

The second issue is that the drive is not actually enabled (presumably since I have yet to discover where to tell the system which Bit is the drive enable output), and consequently the motor does not move.

You can turn on that bit in the program that initializes you system with:

SetBit(145);

For DAC Servos you might follow the steps here and here.

Posted: **Tue Dec 29, 2020 10:25 am**

Thanks Moray,

I understand now about the Halt button only stopping the C program and that commands already sent cannot be recalled. All good, now that I know. As I said previously, I'm currently trying to become familiar with how the whole C program thing operates.

Thanks also for showing me your init files. They certainly have helped me understand some more about the whole process as well.

Thanks Tom for your help.

I had already changed the output from Step Dir to DAC Servo in the axes Config window and then downloaded the settings from the KMotion Config window several times prior to any of this while I was getting things wired up.

In any case, I have now used the C Code -> Clipboard feature to add the axis parameters into the top of the SimpleHomeIndexFunctionTest program. I also added the drive enable output and the drive is now activated by running the program, so that fixes my previous set of issues. Thanks.

The motor is responding to the program now, but only in a very limited way. It seems (largely at least) to ignore the speed and direction settings set in the program for whatever reason! The original speed setting was way too fast for getting things set up and working correctly so I reduced it. Still too fast for my liking, so I reduced it more. I reduced it from 1000 down to 5, doing a Save/Compile/Download/Run each time and it didn't make any difference to the speed the motor was running at.

By playing around with commands from the Console window, I worked out that the motor drive was getting a signal equivalent to a speed value of 200, so I started looking for where that could be coming from. I found that the MaxOutput was specified at 200, so that then made perfect sense for the values larger than 200, but what about the smaller ones? I found that I could control the motor speed by adjusting the value of this setting.

I pretty soon realised that the direction sign made no difference either - it just kept going in the same direction regardless. It will sometimes change direction and speed after a hardware power cycle, but not reliably even after hours of power off completely.

The next issue is that the Home finding part of the program doesn't work at the moment either. Once I got the speed down to something I could cope with, I let it have a go at the main purpose of the program. Unfortunately it either doesn't detect the Home switch or ignores it anyway. I can watch the switch change state as expected on the dig I/O window, but the motor just keeps on going until it stalls against a hard mechanical stop! It doesn't even stop, let alone change direction as it should.

It seems that KFlop will remember some settings but not others through a power cycle. Is that correct?
Is it recommended (or mandatory even) to power cycle it after changing settings and downloading them?

You said that I could turn on the motor drive enable bits in the init program, but how does that work later when the machine is working? As you know, the DAC outputs are not reliably at exactly 0 when told to be 0, so if the drives are always enabled, they could be creeping when they should be completely stopped. How is this handled when a GCode program is running? Surely they will need to be enabled and disabled often, won't they?

As always, I really appreciate the time you guys put into this assistance.

Thanks & have a great day,
Peter

Posted: **Tue Dec 29, 2020 5:06 pm**

hatcat wrote: ↑
Tue Dec 29, 2020 10:25 am

The motor is responding to the program now, but only in a very limited way. It seems (largely at least) to ignore the speed and direction settings set in the program for whatever reason! The original speed setting was way too fast for getting things set up and working correctly so I reduced it. Still too fast for my liking, so I reduced it more. I reduced it from 1000 down to 5, doing a Save/Compile/Download/Run each time and it didn't make any difference to the speed the motor was running at.

By playing around with commands from the Console window, I worked out that the motor drive was getting a signal equivalent to a speed value of 200, so I started looking for where that could be coming from. I found that the MaxOutput was specified at 200, so that then made perfect sense for the values larger than 200, but what about the smaller ones? I found that I could control the motor speed by adjusting the value of this setting.

I pretty soon realised that the direction sign made no difference either - it just kept going in the same direction regardless. It will sometimes change direction and speed after a hardware power cycle, but not reliably even after hours of power off completely.

What speed setting are you changing?
As you're using Servos, the MaxOutput refers to the maximum voltage the analogue DAC output can go to. Depending on if your servo drives work in speed or torque mode, commanding a DAC of 200 will either produce a fixed speed (in the case of speed mode), or a fixed torque (torque mode) which if the motor has little load, will result in it moving at high speed.

The next issue is that the Home finding part of the program doesn't work at the moment either. Once I got the speed down to something I could cope with, I let it have a go at the main purpose of the program. Unfortunately it either doesn't detect the Home switch or ignores it anyway. I can watch the switch change state as expected on the dig I/O window, but the motor just keeps on going until it stalls against a hard mechanical stop! It doesn't even stop, let alone change direction as it should.

Are you sure you're monitoring the correct bit in the homing program?

It seems that KFlop will remember some settings but not others through a power cycle. Is that correct?

Unless you select the option to Flash User Memory (not recommended for normal use!), all settings are lost in a power cycle.

Is it recommended (or mandatory even) to power cycle it after changing settings and downloading them?

All common settings can be changed without power cycling. Lots of the settings can actually be changed on the fly, but you wouldn't normally do that, unless you had a very specific reason to (i.e. changing the tuning of a lathe spindle motor if you swap from spindle mode to position/C axis mode).

You said that I could turn on the motor drive enable bits in the init program, but how does that work later when the machine is working? As you know, the DAC outputs are not reliably at exactly 0 when told to be 0, so if the drives are always enabled, they could be creeping when they should be completely stopped. How is this handled when a GCode program is running? Surely they will need to be enabled and disabled often, won't they?

As long as the KFlop is active and the servo channels configured, the KFlop will maintain the DACs at whatever value they need to be for the motors to remain stationary. The only time they may drift, is if you have a situation where the servo drives become powered/enabled before the KFlop is initialised with the channel values. Your servo enables should be connected so they default to off, until the KFlop is initialised and can actively control them.

Posted: **Tue Dec 29, 2020 6:40 pm**

Hi Peter,

I wouldn't try to home the axes until after they are configured, tested, and tuned. I'm guessing you might have the feedback reversed so as soon as enabled the axis runs away from the target at max output. This is what happens when you have positive rather than negative feedback. Its also like an inverted pendulum the slightest error one way or the other will determine the direction it falls. Please follow the links from my previous post to use the Step Response Screen to enable the axis and verify it holds position, then make moves, increase limits, tune, etc.

Posted: **Tue Dec 29, 2020 10:18 pm**

Thanks very much guys.

I will try tuning etc today and see how that goes.

Would you please give me the correct syntax to print out the value of a variable on the Console screen? I see that the homing program prints some text messages on the screen, but I haven't been able to get it to print variable values despite syntax help from the Internet.

Thanks again,
Peter

Posted: **Tue Dec 29, 2020 11:15 pm**

You use the printf() function to output to the console, however you need to know what kind of number you want to display.

For a double/float, you need to use-

Code: Select all

double x = 89.89;
printf("This is a double:%f",x);

If you're outputting an integer-

Code: Select all

int x = 99;
printf("This is an integer:%d",x);

Then you can combine multiple in the printf-

Code: Select all

int x =17;
float y = 29.28;
double z = 378.38;
printf("We have an int:%d\nA double:%f\nAnd a float:%f", x, z, y);

which if I got that right should output -

Code: Select all

We have an int:17
A double:378.38
And a float:29.28

(I've not tested that code, just made it up!)
There are other options for formatting the output, which if you're concerned about, a google search for printf will through up various tutorials.

If you're ever unsure whether to use %d or %f, just try one and see what happens. If the number looks wrong, try the other one.

There is also the whole C Pointer thing, which is the seemingly random * and &'s you see when using some variables, so if you end up with a seemingly random number showing, you're probably printing the memory location of the variable, not the actual value. I'm not even going to attempt to explain pointers, as although I understand them and the theory on how to use them, I don't use them enough, and nearly always get the syntax wrong.

Posted: **Wed Dec 30, 2020 12:15 am**

Note KFLOP only prints the line after getting a newline character. So there should always be a \n at the end like this:

printf("This is a double:%f\n",x);

Posted: **Wed Dec 30, 2020 9:50 am**

Hi Moray,

Thanks very much for the printing explanation. That's quite different from what I got from the Internet, so no wonder it didn't work!
Now to answer some of your questions.

What speed setting are you changing?

The one shown here.

I realised what MaxOutput was about. That's how I was reducing the speed since it seemed to be ignoring the one above.
The motor drives are Speed Mode.

Are you sure you're monitoring the correct bit in the homing program?

I'm monitoring this Bit shown here. If this is not what I should be looking at, then I will need help to find the correct one please.

This one turns on and off when I operate the switch by hand.

Thanks very much for the other info too.

Hi Tom,

I have tuned my motors to the best of my current ability. Thanks for the direction to do that next. You were correct about the feeedback being reversed.
The first is the X axis, followed by the Z axis and then the Spindle.

As you can see, the Spindle has quite a sizeable Following Error (if that's the correct term) and I cannot reduce it significantly using the Integral term as I was able to do quite successfully with both X and Z. In fact it becomes unstable before it has had any significant effect at all. X & Z behaved themselves pretty much like 'text book' cases.

Since it is the Spindle, perhaps it won't matter so much, although I would like to be able to do single point thread cutting with it. Maybe I can play around with the motor drives later and see what I can find there, but for now it will do. On with continuing to get my head around the C programming stuff tomorrow!

Thanks again for all your help, and have a great day!

Peter

Dynomotion Forum

C program control issues

C program control issues

Re: C program control issues

Re: C program control issues

Re: C program control issues

Re: C program control issues

Re: C program control issues

Re: C program control issues

Re: C program control issues

Re: C program control issues

Re: C program control issues