Homing setup and issues

[RogerFroud]

I've been trying to implement homing using the HomeMM_V8.c example program and have almost sorted it out now.

The example is cleverly written, although a few more comments would be helpful in trying to understand how it works. So much of it looks the same, and it's hard to follow. I've attached my commented version which might assist some users who are having the same issues.

The main problem has been that I'm using a regime where the Limit Switch bits are normally high, and go low when the switch is activated. This ought to be a trivial change, because the seventh parameter in CreateHomeTask is intended to invert the action of the bit.

However, there are at least two bugs that I've found that stop this working as intended. If you open the Modified HomeMM_V8.c and search for BUG, you'll see the issues. The first one does an absolute test on the Limit switch bit, regardless of the state of the user limit switch state required.
The second one looks to me like it never rolls off the Limit switch regardless of the user state because the test is == and not != as needed.

With those two bugs corrected, the X-axis now homes correctly. In other words, it correctly gets off the switch if it's on it already, goes onto the switch, and then off again.

The eighth parameter passed to the CreateHomeTask() function is labelled encoderbit, and that appears to reference KFLOP bits 0-15.

I've connected those as shown in the attached Schematic, so I think that makes my marker bits as follows...
#define X_MARKER_BIT 2
#define Y_MARKER_BIT 6
#define Z_MARKER_BIT 10
#define A_MARKER_BIT 14

So even though the Digital I/O KFLOP page shows bits 8-15 as Home and Limits, they are connected to encoder channels on my board.
What's confusing is that when I click Reboot! in the KMotion Console, I find that the Output check boxes change to how they appear on the attached Digital IO.JPG screen shot.

Why do bits 8,9,10,12,13 & 15 all revert back to outputs after a reboot? How can I force them to stay set to Inputs?

[TomKerekes]

Hi Roger,

Thanks for the 2 bug fixes.

On bootup KFLOP attempts to auto detect a Kanalog. It basically assumes a Kanalog is present and reads the 8 ADCs on Kanalog and if any are invalid or at full scale KFLOP assumes that the Kanalog is not present. It seems your system is falsely detecting a Kanalog. The Input bit 14 would have to toggle in a very particular manner for this to happen. You might make sure it is disconnected or pulled up or down during boot.

The integer value KanalogPresent would be set to 1 when a Kanalog is detected. You might print it to check this.

You might Flash New Version to check if this flag was somehow inadvertently set and Flashed to KFLOP.

If it is being falsely detected, it simply can be reset to 0 and the IO set to your needs by your Init Program.

Another option is to set the variable DisableKanalogDetectOnBoot=1 and Flash User Data to prevent Kanalog from ever being auto detected.

[RogerFroud]

I think we're at crossed purposes. I do have a KANALOG board fitted, and I'm using the KANALOG JP1 & JP2 inputs for the Encoders including the reference channels. I'm also using the KANALOG opto inputs JP15 for the limit switches and JP8 JP11 & JP13 too. (See attached schematic)

I tried adding this line...
printf("KanalogPresent=%d",KanalogPresent);
... at the start of the Homing program and got the value 1 returned. I'm not sure whether this was how you intended me to print that value, but it did work.

So it looks like the KANALOG board is correctly being detected, since it is fitted.

When you say to "Flash New Version", I presume you mean to press the NEW VERSION button in the Configuration window. That offers me a file called DSPKFLOP.out which is dated 14/8/2018 so I used that one. This made no difference.

If I reboot and leave the KFLOP bits 8-15 as they are set by that (see the screen shot on my first post) then KMotionCNC will initialise and the jogs work on X,Y & Z
However, if I uncheck all of the output check boxes, it doesn't work any more. There appears to be some conflict between what KFLOP is using those bits for and what KANALOG is using. My guess is that they're assigned to two different things that you can't use at the same time.

If you look at the schematic, you can see what I've assigned everything to, including the bit numbers. Hopefully that will make it clear what I'm doing.

Looking again at the KFLOP GPIO JP7 pin assignments (see attached screen shot), it seems to me that the conflict is that I'm using the alternate Step & Directions on the Auxiliary ports, and that should free up the pins IO8-IO15. My guess is that although the Step & Direction outputs are being correctly routed to the Auxiliary ports because they work, KFLOP doesn't correctly disconnect them from the pins on JP7 which should be free to use the alternate functions listed on the connector.

This would explain why it doesn't jog any more when I force the outputs to be inputs. It looks like those disable the outputs on the auxiliary connectors which I'm using as outputs. In other words, the direction check boxes for KFLOP pins 8-15 seem to be shared with the ones oncthe auxiliary connectors. Those should be separate in my opinion, since you ought to be able to have the Step & Direction outputs on the auxiliary port and their alternate pins on the GPIO port being inputs.

[TomKerekes]

Hi Roger,

My mistake. I assumed you didn't have a Kanalog otherwise why would you be trying to use or reconfigure IO on KFLOP JP7? When Kanalog is connected to KFLOP JP7 it consumes that connector and the associated IO. If the IO on KFLOP JP7 is reconfigured that will cause the communication between KFLOP and Kanalog to fail. Don't do that. That is why you redirected the Step/Dir Outputs to KFLOP JP4/JP6.

I don't understand the problem you are having.

[RogerFroud]

If you look at the schematics I posted, you will see that I'm using both JP1 & JP2 inputs for encoder channels. The KANALOG manual explicitly names them as differential encoder inputs on both JP1 & JP2. What bits are those assigned to for accessing the reference channels? I assumed that JP1 & JP2 were mapped to b0-15 on the Digital I/O page since the bits 0-7 are clearly connected to the X & Y encoders because I can see them move.

My expectation was that the other bits 8-15 will map to JP2 inputs but they don't. Maybe they are shown elsewhere? They are labelled as Home and Limit connections on the Digital I/O page, but they're apparently outputs according to that page. They appear to be assigned to something else that interferes with the Step & Direction outputs if I force them to be inputs. I don't understand what those pins 8-15 are being used for.

I'm using encoder channel number 4 for the Z-axis which definitely works, and that's connected to JP2. However, I can't see that changing bits in the Digital I/O page, so where can I view those?

So specifically, my problem is that I need to know what bits to tell the Homing software to use for the Z-axis and reference channel? What are the JP2 KANALOG bits bit assignments?

[TomKerekes]

Hi Roger,

Kanalog JP2 inputs are converted to single ended and connected to KFLOP I/O bits 36-43 (KFLOP JP5 Pins 1-8) which are General Purpose I/O pins or encoder inputs 4-11.

HTH

[RogerFroud]

Ok, thanks for that, I can see those changing as I jog the Z-axis. I'll make sure I'm using the right bit for the Z-axis reference.

I've found some more issues with the attached homing file. Uncommenting the X & Y homing procedures didn't work because the Z axis was still being used for both of them. If you search for BUG in the attached modified copy, you will see where I've marked it up.

I also notice that the function prototype for CreateHomeTask doesn't match the function definition. It looks like this was modified because of a restriction of the number of parameters that can be passed to a function.

I don't know why the compiler doesn't complain about this.

Anyway, slow but steady progress is being made. It now homes in all three axes. I'll get back to the tuning shortly and look at the Spindle interface.

[RogerFroud]

I've really struggled to set up the soft limits because for some reason the moves used in the homing sequence are checking the position against the soft limits. During homing, the system needs to ignore the soft limits, they only become valid when the machine has homed. It's easily possible to get the machine into a position where it's impossible to get it to home again, since it goes into feed hold.

Does anyone actually use this function, because as written, it's not viable?

I've attached my solution to this which is a little clumsy, but it works. An array might have been cleaner, but this will do.

Basically I define some local variables in the homing routine and save the values that are defined in the Initialisation program, having been copied from the Configuration window. I just copy all of the soft limit values into temporary variables and then overwrite the limits with +/-1e9 to make them inactive. Once homing is complete, the original values are copied back. This means it doesn't matter if the table is a long way from the limit switch and the machine zero is at that point.

Hopefully someone will find this useful. Ideally, all of these changes would be in the default HomeMM_V8.c routine so that everyone else doesn't have to go through this same procedure.

The following is how I've set the Soft Limits on my machine.

Finding the Soft limit values...

Now I've disabled the limits during homing, this can be done as follows...

1. Select 'Disallow drive into limit' on each axis in the Configuration page. The other check boxes are unchecked.
2. Home the machine in KmotionCNC with the limits set to +/-1e9 so they're well out of the way when they are enabled after homing.
3. Use the Export All to Open C Program (initialisation C file) and save it.
4. Home the machine.
5. Get the Digital I/O page up with the KANALOG tab displaying bits 136-141
6. Any bit that's clear represents a limit switch that's open. 136 is X+ etc
7. Jog somewhere near to the limit you want to find and then step 1mm at a time until the limit switch shows on the Digital I/O page.
8. Look at the Machine DRO for the axis you're setting and note the position. If this is the positive direction, multiply the number by the number of steps you would need to go to this position. If the DRO measured 1.9mm, say, and the machine requires 4000 steps per mm, the count is 1.9*4000=7600. This is the figure you put in the Soft Limit + box for that axis.
9. Use the Export All to Open C Program (initialisation C file) and save it.
10. Reboot the machine, initialise and Home it again.
11. Jog near to the end and step 1mm at a time until it stops which should be with the switch showing on the Digital I/O page.
12. Small adjustments can be made to the figures if it overshoots when approached at speed for example, or it doesn't quite trip the limit switch and you could get more travel.