Group: DynoMotion	Message: 12814	From: d_triezenberg	Date: 2/21/2016
Subject: Unexpected behavior of C function DefineCoordSystem()

I have been closely following the procedure in the KSTEP Basics Tutorial in order to bring up my 3 axis engraving mill, which uses open loop steppers. The Step Response screen works correctly (i.e., the motor for the selected axis will move and then return). So I have adjusted V,A,J and created an init.c file that includes the statement

DefineCoordSystem(0,1,2,-1)

The problem is that when I start up KmotionCNC, I cannot jog any of the 3 axes; they do not move when the buttons are clicked. So I am not ready to proceed with G code.

In an effort to debug, I can go back to Kmotion and find that the Step Response screen no longer works. I can only make it work again by cycling power to KFLOP/KSTEP and NOT running my init.c file. The same behavior occurs with the Console screen; a MoveRel script command works only if I have NOT run the init.c file.

By trial and error, I find that the statement that has seized all axis motion is the DefineCoordSystem() statement. If I remove it from init.c, then I can run the Step Response moves, and MoveRel on the Console. This is entirely unexpected; I thought the DefineCoordSystem() was just providing some information needed by KmotionCNC.

Question 1) What is it that I do not understand?

Additional information:

I am running software version 4.33, but my USB driver is from 4.34 (signed).

I have wired 6 microswitches as NC limit switches, and the relevant statements in init.c are

ch0->LimitSwitchOptions = 0x123;

ch0->LimitSwitchNegBit = 169;

ch0-LimitSwitchPosBit = 168;

and similar for ch1 and ch2 (170,171,172,173).

I have wired the switches (through a simple breakout board) to pins 9-14 of KSTEP J36. 24 volt power is on pin 8 and all switches complete a circuit to 24 volt return. The Digital I/O screen of Kmotion (KSTEP Tab) shows that one of these opto inputs will transition from checked (high?) to unchecked (low?) when I manually depress a switch.

I have two related questions on the size of steps. My motors are 200 steps/rev. I find that 3200 "counts" on the Step Response screen causes one full revolution of the motor. This seems to be independent of the value assigned to chX->InvDistPerCycle in the init.c file. I also get one full revolution from the script statement

MoveRel0 = 3200

Question 2) Does parameter chX->InvDistPerCycle have any effect on the functioning of Kmotion screens?

Question 3) Do I correctly infer that 16 "counts" are one full revolution?

Dave

Group: DynoMotion	Message: 12815	From: Moray Cuthill	Date: 2/21/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Hi Dave,

it would probably be wise to attach your init.c file (even just copy&paste the contents, as it makes it easier to read via email) just to check for any obvious errors.

When trying to control via KMotionCNC, keep KMotion open in the background with the console screen open and see if there are any error message being generated by the KFlop.

Regarding the 3200 steps, KStep uses 16x microstepping, so the 3200 figure is correct (200 motor steps x 16 microsteps).

Moray

On Sun, Feb 21, 2016 at 10:14 PM, d.triezenberg@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

I have been closely following the procedure in the KSTEP Basics Tutorial in order to bring up my 3 axis engraving mill, which uses open loop steppers. The Step Response screen works correctly (i.e., the motor for the selected axis will move and then return). So I have adjusted V,A,J and created an init.c file that includes the statement
DefineCoordSystem(0,1,2,-1)
The problem is that when I start up KmotionCNC, I cannot jog any of the 3 axes; they do not move when the buttons are clicked. So I am not ready to proceed with G code.
In an effort to debug, I can go back to Kmotion and find that the Step Response screen no longer works. I can only make it work again by cycling power to KFLOP/KSTEP and NOT running my init.c file. The same behavior occurs with the Console screen; a MoveRel script command works only if I have NOT run the init.c file.
By trial and error, I find that the statement that has seized all axis motion is the DefineCoordSystem() statement. If I remove it from init.c, then I can run the Step Response moves, and MoveRel on the Console. This is entirely unexpected; I thought the DefineCoordSystem() was just providing some information needed by KmotionCNC.
Question 1) What is it that I do not understand?
Additional information:
I am running software version 4.33, but my USB driver is from 4.34 (signed).
I have wired 6 microswitches as NC limit switches, and the relevant statements in init.c are
ch0->LimitSwitchOptions = 0x123;
ch0->LimitSwitchNegBit = 169;
ch0-LimitSwitchPosBit = 168;
and similar for ch1 and ch2 (170,171,172,173).
I have wired the switches (through a simple breakout board) to pins 9-14 of KSTEP J36. 24 volt power is on pin 8 and all switches complete a circuit to 24 volt return. The Digital I/O screen of Kmotion (KSTEP Tab) shows that one of these opto inputs will transition from checked (high?) to unchecked (low?) when I manually depress a switch.
I have two related questions on the size of steps. My motors are 200 steps/rev. I find that 3200 "counts" on the Step Response screen causes one full revolution of the motor. This seems to be independent of the value assigned to chX->InvDistPerCycle in the init.c file. I also get one full revolution from the script statement
MoveRel0 = 3200
Question 2) Does parameter chX->InvDistPerCycle have any effect on the functioning of Kmotion screens?
Question 3) Do I correctly infer that 16 "counts" are one full revolution?
Dave

Group: DynoMotion	Message: 12816	From: Tom Kerekes	Date: 2/21/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Hi Dave,

You seem to have some typo errors in your email. Please attach your init.c program so we can see exactly what it is.

It seems your limit switches cause the input to go low (unchecked) when triggered. So you should use the "Stop when low" option. Which would (if you aren't using KMotion to generate the code for you) is:
ch0->LimitSwitchOptions=0x12f;

Otherwise all your axes will be always disabled due to Limit Switch conditions. If this is the case it should be obvious because disable messages will appear on the Console Screen and the Axis Screen will show all the Axes not enabled.

InvDistPerCycle has no effect on Step Pulse and Direction Drives such as KStep.

16 motor step pulses generate one full step with KStep. So with a standard 200 full step/rev stepper motor there are 3200 "steps" per revolution.

Regards
TK

On 2/21/2016 2:14 PM, d.triezenberg@... [DynoMotion] wrote:

I have been closely following the procedure in the KSTEP Basics Tutorial in order to bring up my 3 axis engraving mill, which uses open loop steppers. The Step Response screen works correctly (i.e., the motor for the selected axis will move and then return). So I have adjusted V,A,J and created an init.c file that includes the statement

DefineCoordSystem(0,1,2,-1)

The problem is that when I start up KmotionCNC, I cannot jog any of the 3 axes; they do not move when the buttons are clicked. So I am not ready to proceed with G code.

In an effort to debug, I can go back to Kmotion and find that the Step Response screen no longer works. I can only make it work again by cycling power to KFLOP/KSTEP and NOT running my init.c file. The same behavior occurs with the Console screen; a MoveRel script command works only if I have NOT run the init.c file.

By trial and error, I find that the statement that has seized all axis motion is the DefineCoordSystem() statement. If I remove it from init.c, then I can run the Step Response moves, and MoveRel on the Console. This is entirely unexpected; I thought the DefineCoordSystem() was just providing some information needed by KmotionCNC.

Question 1) What is it that I do not understand?

Additional information:

I am running software version 4.33, but my USB driver is from 4.34 (signed).

I have wired 6 microswitches as NC limit switches, and the relevant statements in init.c are

ch0->LimitSwitchOptions = 0x123;

ch0->LimitSwitchNegBit = 169;

ch0-LimitSwitchPosBit = 168;

and similar for ch1 and ch2 (170,171,172,173).

I have wired the switches (through a simple breakout board) to pins 9-14 of KSTEP J36. 24 volt power is on pin 8 and all switches complete a circuit to 24 volt return. The Digital I/O screen of Kmotion (KSTEP Tab) shows that one of these opto inputs will transition from checked (high?) to unchecked (low?) when I manually depress a switch.

I have two related questions on the size of steps. My motors are 200 steps/rev. I find that 3200 "counts" on the Step Response screen causes one full revolution of the motor. This seems to be independent of the value assigned to chX->InvDistPerCycle in the init.c file. I also get one full revolution from the script statement

MoveRel0 = 3200

Question 2) Does parameter chX->InvDistPerCycle have any effect on the functioning of Kmotion screens?

Question 3) Do I correctly infer that 16 "counts" are one full revolution?

Dave

Group: DynoMotion	Message: 12817	From: d_triezenberg	Date: 2/21/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Moray,

Thanks for your response. TK also answered and identified the problem as inverted logic on my limit switches. So I will spare you all the detail of the init.c file.

Dave

Group: DynoMotion	Message: 12818	From: d_triezenberg	Date: 2/21/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Tom,

You have identified the problem; I changed the limit switch options and all problems are resolved. KmotionCNC is now producing jogs.

Somehow, I had been able to look at the Kmotion Configuration screen several times and convince myself that NOT checking "Stop when low" was the right thing to do.

Thanks,

Dave

Group: DynoMotion	Message: 12823	From: d_triezenberg	Date: 2/22/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Attachments :

init-12823(1).c

Tom,

Following your message yesterday, I changed the limit switch options parameter from 0x123 to 0x12f (for all 3 axes), and all was then functional, Kmotion and KmotionCNC.

You said that the Console screen should have been giving messages that the axes were disabled. I have been watching the Console screen all along, but saw no such messages. I cannot say about the Axis screen, since I was not monitoring it.

Today I have apparently done something unintended, as the 3 axes are once again not moving. I am getting no Console messages indicating problems. The Axis Screen shows that all 3 axes are enabled. I have attached my init.c file. At the time that I lost motion, I was attempting to change ch1->OutputGain from 1 to -1 so that moves (by console script command or by KmotionCNC) would go the right direction.

I am thinking that I do not see all Console messages. When I power up, there is a date and time stamped message (Kmotion program started). When I send a script command, it is echoed back, along with "KFLOP 4.33" and "Ready". But, my init.c file contains a printf() message, and I do not see that argument string, either from power up or when I run init.c from the C Program screen.

I also question if things are working correctly when I am using the C Program screen. On Compile, I always get a message declaring No Errors, plus some text/bss/data statistics. But there is no message when I click Download or Run, leaving me to wonder whether anything has happened. That the Console screen does not show my printf() string is additional unsettling evidence.

Please advise if you see something amiss in the init.c file. I have been enabling the axes by the KFLOP J6 pin (+3.3v) rather than by bit 45.

Dave

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

On 2/21/2016 2:14 PM, d.triezenberg@... [DynoMotion] wrote:

I have been closely following the procedure in the KSTEP Basics Tutorial in order to bring up my 3 axis engraving mill, which uses open loop steppers. The Step Response screen works correctly (i.e., the motor for the selected axis will move and then return). So I have adjusted V,A,J and created an init.c file that includes the statement
DefineCoordSystem(0,1,2,-1)
The problem is that when I start up KmotionCNC, I cannot jog any of the 3 axes; they do not move when the buttons are clicked. So I am not ready to proceed with G code.
In an effort to debug, I can go back to Kmotion and find that the Step Response screen no longer works. I can only make it work again by cycling power to KFLOP/KSTEP and NOT running my init.c file. The same behavior occurs with the Console screen; a MoveRel script command works only if I have NOT run the init.c file.
By trial and error, I find that the statement that has seized all axis motion is the DefineCoordSystem() statement. If I remove it from init.c, then I can run the Step Response moves, and MoveRel on the Console. This is entirely unexpected; I thought the DefineCoordSystem() was just providing some information needed by KmotionCNC.
Question 1) What is it that I do not understand?
Additional information:
I am running software version 4.33, but my USB driver is from 4.34 (signed).
I have wired 6 microswitches as NC limit switches, and the relevant statements in init.c are
ch0->LimitSwitchOptions = 0x123;
ch0->LimitSwitchNegBit = 169;
ch0-LimitSwitchPosBit = 168;
and similar for ch1 and ch2 (170,171,172,173).
I have wired the switches (through a simple breakout board) to pins 9-14 of KSTEP J36. 24 volt power is on pin 8 and all switches complete a circuit to 24 volt return. The Digital I/O screen of Kmotion (KSTEP Tab) shows that one of these opto inputs will transition from checked (high?) to unchecked (low?) when I manually depress a switch.
I have two related questions on the size of steps. My motors are 200 steps/rev. I find that 3200 "counts" on the Step Response screen causes one full revolution of the motor. This seems to be independent of the value assigned to chX->InvDistPerCycle in the init.c file. I also get one full revolution from the script statement
MoveRel0 = 3200
Question 2) Does parameter chX->InvDistPerCycle have any effect on the functioning of Kmotion screens?
Question 3) Do I correctly infer that 16 "counts" are one full revolution?
Dave

@@attachment@@

Group: DynoMotion	Message: 12830	From: Tom Kerekes	Date: 2/22/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Hi Dave,

Do you have a limit switch condition?

Is there a Limit Stop Axis:1 message on the Console Screen?

Is the Yellow FeedHold button flashing?

Regards
TK

On 2/22/2016 4:44 PM, d.triezenberg@... [DynoMotion] wrote:

Tom,

The addition of a newline character to the printf() argument string has the desired effect, the message now prints to the console. It has been some years since I regularly programmed C.

Agreed about I/O bit 45, it remains an input. The Digital I/O screen shows it going high and low in response to my "Enable" toggle switch.

On the Axis screen, both Dest and Position show as zero for all 3 axes. When I send the script command "MoveRel1=3200", there is no change in this display, not even a momentary flicker. The 3 axes are indicated as enabled.

Thanks for your attention,

Dave

Group: DynoMotion	Message: 12832	From: d_triezenberg	Date: 2/22/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Tom,

All 6 limit switches are in their normally closed condition, since the axis positions are all near center. On the Digital I/O screen, there are check marks for bits 168-173. I can make any one of the checks clear by manually depressing the corresponding switch.

There are no console messages about limit switch conditions, and none are generated when I manually depress a switch.

On the KmotionCNC display, the yellow Feed Hold is not blinking. It does not blink when I manually depress a limit switch.

Dave

Group: DynoMotion	Message: 12834	From: Tom Kerekes	Date: 2/22/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Hi Dave,

I don't know what could be the problem This is very basic. It worked for me although I had to reverse the Limit Switch Polarity because I don't happen to have 6 limit switches connected.

The Limit Stop Axis message and feedhol will only occur when the axis is in motion and the limit is activated.

Try these steps:

#1 power off KFLOP
#2 exit KMotion.exe and all other Apps
#3 run KMotion.exe (open C Programs with your init.c in Thread #1, Console Screen, Axis Screen)
#4 power on KFLOP wait for KFLOP to indicate Connected
#5 Push button with all the arrows on the C Program Screen
#6 Verify "Program init.c has run." on Console Screen
#7 Verify Axis Screen shows #0 #1 #2 enabled
#8 Enter "MoveRel1=3200" Send on Console Screen
#9 Verify Axis Screen #1 Dest changes to 3200

HTH
Regards
TK

On 2/22/2016 6:14 PM, d.triezenberg@... [DynoMotion] wrote:

Tom,

All 6 limit switches are in their normally closed condition, since the axis positions are all near center. On the Digital I/O screen, there are check marks for bits 168-173. I can make any one of the checks clear by manually depressing the corresponding switch.

There are no console messages about limit switch conditions, and none are generated when I manually depress a switch.

On the KmotionCNC display, the yellow Feed Hold is not blinking. It does not blink when I manually depress a limit switch.

Dave

Group: DynoMotion	Message: 12840	From: d_triezenberg	Date: 2/23/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Attachments :

init-12840(1).c

Tom,

I followed your steps. All was OK until step 9; Dest did not change and the motor did not move.

I then proceeded as follows:

1. At C Program window, create a 1 line "Hello, World" program. Compile, Download, Run with the one button.

2. Flash this new program into thread 1, so that init.c will not run at power-up.

3. Close Kmotion, power down KFLOP/KSTEP.

4. Restart Kmotion, open windows Console, Axis, C Program

5. (C Program window) Open init.c

6. Power up KFLOP/KSTEP, wait until connected

7. (Config & Flash window) Import All from Open C Program

8. (Digital I/O window) set bit 0 as output and state as "checked" - I need this for the hardware enable signal at KSTEP J6. Now I can hear that the motors have power.

9. (Step Response window, chan 0) click Move. Motor indexes back & forth, changing Dest shows in Axis window.

10. (Console window) Send "MoveRel0=3200". Motor makes a full revolution and Dest changes to 3200

11. (C Program window) Compile, Download, Run init.c using the one button

12. (Step Response window) click Move. No response from motor or Dest in Axis window.

13. (Console window) Send "MoveRel0=3200". No motor response, no change to Dest

I am at at a loss to explain the result of steps 12 & 13. I have attached a new copy of init.c to this message; I have been editing it some and could have inadvertantly changed something.

At this point, I am thinking that it is time to uninstall the Kmotion software and then reinstall. Is it OK to use the 4.34 (signed?) USB driver with version 4.33?

Dave

@@attachment@@

Group: DynoMotion	Message: 12845	From: Tom Kerekes	Date: 2/23/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Hi Dave,

Very strange. I wired up 6 Limit Inputs to KStep and the external Enable to 3.3V so I could run your exact init.c program (the last one you posted). My 9 step process works as expected and creates Motion and Dest changes on the Axis Screen.

I noticed your init.c file has ch2->OutputChan=11; instead of 10 as I would expect. I suspect that is why you don't see Z motor movement unless you intentionally wired the Z motor to KStep Output #3 instead the normal #2.

Running a C Program from a KMotionCNC User Button or From KMotion.exe C Program Screen should do exactly the same thing. Are you absolutely sure you have the same file and path loaded/specified in both?

Regards
TK

On 2/23/2016 9:51 AM, d.triezenberg@... [DynoMotion] wrote:

Tom,

A bit more info on this puzzling situation:

I find that if I launch KmotionCNC (after a power down state of KFLOP) and push the init button (which is set up to run my init.c program), then I can jog the X and Y axes. Z does not jog, but the Z display increments.

Then if I launch Kmotion also, and NOT run init.c, I get motor motion from Console Script commands for X & Y (0 & 1). Again, no Z motor motion, but Dest on the Axis window changes.

If I then run init.c from the C Program window, the motors no longer react to Console Script move commands.

Dave

Group: DynoMotion	Message: 12847	From: d_triezenberg	Date: 2/23/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Tom,

Indeed it was the output channel 10/11 mix up that preventing Z jogs.

I do have the same init.c path for both programs, C:\KMotion433\C Programs\init.c.

So I am still not up and running with Kmotion yet, although I may be able to try out some G code on KmotionCNC.

If I need to invert directions on an axis, is it OK to make chX->OutputGain = -1, or is there a better way?

Dave

Group: DynoMotion	Message: 12848	From: TKSOFT	Date: 2/23/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Hi Dave,

That's bizarre.

What button are you using to Save/Compile/Download/Run on the C Program Screen?

Are you using Thread #1 in both cases (although I can't see why that would matter just trying to eliminate variables)

As a sanity check after running the init.c form the C Programs Screen if you "Upload" each of the channel Axes do the screen cells on the Config/Flash and Step Response Screen all look as expected?

Are you sure there are never any messages on the Console other than your printf?

Are you sure the FeedHold button isn't blinking?

You might temporarily disable all Limits as a test by setting the LimitSwitchOptions to zero in the init.c program.

Otherwise I may need to TeamViewer into your system to see it first hand to try to figure it out.  Is that a possibility?

Yes chX->OutputGain=-1; can be used to reverse a Step/Dir axis.

Regards
TK

On 2016-02-23 10:29, d.triezenberg@... [DynoMotion] wrote:
 > Tom,
> Indeed it was the output channel 10/11 mix up that preventing Z jogs.
> I do have the same init.c path for both programs, C:\KMotion433\C
> Programs\init.c.
> So I am still not up and running with Kmotion yet, although I may be
> able to try out some G code on KmotionCNC.
> If I need to invert directions on an axis, is it OK to make
> chX->OutputGain = -1, or is there a better way?
> Dave 
>  
>

Group: DynoMotion	Message: 12854	From: d_triezenberg	Date: 2/23/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Tom,

1. What button do I use for Save/Compile/Download/Run? It is the one the far right, which combines several arrow directions. I started using it at your suggestion.

2. Yes, I can confirm that thread #1 is indicated both in KmotionCNC setup and Kmotion C Program window. I have never intentionally selected any other thread for any purpose.

3. I have used the "Upload" and looked at the parameter boxes on both Config & Flash and Step Response. I think that I can properly correlate them to the members of struct CHAN, and they all look correct. I have now changed OutputGain to -1 for channels 1 and 2, and this is what is shown.

4. The console messages that I see are

a. "Kmotion has started", evidently a power up message.

b. The printf() from my init.c, if I run it from Kmotion.

c. MoveRel echoes (3 lines each)

5. Is feedhold blinking? No. Earlier today, when I was able to jog all 3 axes, I deliberately ran one of the axes to the limit switch and Feedhold started to blink.

6. Disabling limits: I edited init.c to substitute 0x000 for 0x12f on all 3 axes. Behavior was the same; I could jog axes in KmotionCNC, or do Console Script moves in Kmotion, up until I ran init.c from Kmotion.

7. Is it possible to run a Teamviewer session? I would have to learn how to use Teamviewer. Before we go to such drastic measures, I should install your software on a newer computer and see if the problem goes away. I have been trying to run on my old XP laptop. Microsoft does not support it any more, and you should not have to, either. Tomorrow (Wed) will be taken up by some civic duties, but Thursday I can do an install on my Windows 10 laptop. Will let you know what happens.

Thanks for your attention,

Dave

Group: DynoMotion	Message: 12857	From: d_triezenberg	Date: 2/25/2016
Subject: Re: Unexpected behavior of C function DefineCoordSystem()

Tom,

I loaded the Kmotion software onto my newer laptop that runs Windows 10. Form this computer, I am finding no problems with Kmotion or KmotionCNC.

Thank you for all the help - sorry to take up so much time.

Dave