Single KSTEP STEP/DIR from JP26 & JP36

[a_j_p]

I see that KSTEP can accept STEP/DIR signals from both JP26 and JP36, and I have done so successfully using 2 KSTEPs in another system. However, now I am building a new system with just a single KSTEP and am hoping to use JP36 for X/Y STEP/DIR and JP26 for Z STEP/DIR. Is this possible and how?

The reason for this being so that I can use an off the shelf plasma THC such as this https://eagleplasma.net/product/proma-thc-150-sd/on the Z axis only - feeding the STEP/DIR signals from the KFLOP to the THC and then into the KSTEP. Working with RJ45 is going to be much simpler for me (easy to find simple breakout boards and cables, etc.) than the 26 pin ribbon cable without making a total mess.

I could also do all (XYZ) STEP/DIR through JP26 if that makes things easier - but I figured if I could use JP36 for everything but the Z axis I only have to run additional cables for the Z and it keeps things simpler/easier to wire.

Thanks!

[TomKerekes]

Hi,

The Step/Dir signals on JP26 and JP36 are simply wired in parallel.

If signals are fed into JP26 with JP36 also connected to KFLOP then the common pins on KFLOP should be left as Inputs and not otherwise configured as Step/Dir Pins. The pins are diode clamped to the 3.3V supply so should not be hard driven (more than 10ma) above 3.8V by the external device.

Note the external device will need to source current and have a common GND with KFLOP.

HTH

[a_j_p3]

Thanks for the response - sorry I am not super quick at understanding electronics...

My understanding is: the Step/DIR signals coming into the KSTEP from both JP26 and JP36 are connected to each other somewhere (typically not intended for both connectors to be present I assume?). So If using signals from JP26 (but still with JP36 connected to the KFLOP) the common pins become KFLOP_JP7_15-22, is that correct?

Leaving me with 2 options:
Option 1: run all step/dir signals through JP26 and ensure that I/O 8 - I/O 15 (JP7 15-22) and not programmed as outputs (just leave them alone and they should stay as inputs).
OR
Option 2: run X/Y step/dir signals through JP36 via JP7 15-20 (Y is a gantry w/ 2 steppers) and Z through JP26 and just make sure I leave I/O 14 - I/O 15 (JP7 21-22) as inputs.

Is that correct?
If yes, and no disadvantages one way vs. the other, I may actually choose Option 1 above and run all Step/dir through JP26 but leave JP36 connected as a simple way to connect the other necessary pins between the KSTEP and KFLOP.

I assume that if I proceed this way - configuration for the motors in KMotion would correspond to Output Channels of 12-15. Is that correct?

One final question - I understand your comment about the external device requiring a common GND with KFLOP - but are you also saying that power should be supplied through the KFLOP as well (like via the 12V that can be run through it)? Or if I supply power to it directly from the power supply but ensure common ground is enough?

Thanks again!

[a_j_p]

I guess a final question - will I ruin something this way if I accidentally configure the wrong channel in the config and flash screen? Would I be better off doing all step/dir through JP26 and not connecting JP36 (just jumpering power, gnd + enable between kstep J6 and kflop JP7)?

[TomKerekes]

My understanding is: the Step/DIR signals coming into the KSTEP from both JP26 and JP36 are connected to each other somewhere (typically not intended for both connectors to be present I assume?).

correct

So If using signals from JP26 (but still with JP36 connected to the KFLOP) the common pins become KFLOP_JP7_15-22, is that correct?

correct. KFLOP JP& pins 15-22 will be connected to KFLOP JP5 pins 1-8

Option 1: run all step/dir signals through JP26 and ensure that I/O 8 - I/O 15 (JP7 15-22) and not programmed as outputs (just leave them alone and they should stay as inputs).

I don't understand what you mean by this. Maybe make a wiring diagram. I thought the idea was not to split cables.

Option 2: run X/Y step/dir signals through JP36 via JP7 15-20 (Y is a gantry w/ 2 steppers) and Z through JP26 and just make sure I leave I/O 14 - I/O 15 (JP7 21-22) as inputs.

Yes that seems like the best approach. Channels 8, 9, 10 would drive your X and dual Y axes. Your other device would drive Z

I assume that if I proceed this way - configuration for the motors in KMotion would correspond to Output Channels of 12-15. Is that correct?

I don't follow this

I understand your comment about the external device requiring a common GND with KFLOP - but are you also saying that power should be supplied through the KFLOP as well (like via the 12V that can be run through it)? Or if I supply power to it directly from the power supply but ensure common ground is enough?

The 4 Step/Dir inputs on KStep have a common GND. The Step/Dir inputs need to be sourced to 2.4V relative to that GND. KFLOP has a common GND with KStep through JP7 - JP36 for this. I didn't see any specification for your plasma device for what kind of output or supplies it needs. If it needs a 5V supply you might use KFLOP's 5V supply or some other separate 5V supply. But either way there must be a GND connection. If the Plasma device is very noisy with the plasma noise not well isolated from its logic GND and you connect that to KFLOP GND then you might have noise problems with KFLOP. Hopefully that is not the case but it is something you should be aware of.

will I ruin something this way if I accidentally configure the wrong channel in the config and flash screen?

Well be careful not to do this But it is not likely to cause permanent damage. If two outputs are connected together and one is trying to drive high and the other low then the outputs will fight. But each has a current limit of ~20ma so should not cause permanent damage. A similar situation could occur with the Plasma output trying to drive the KStep Input while KFLOP is enabled also trying to drive it. So make sure each KStep Input only has one source

HTH

[a_j_p3]

Thanks again Tom.

Regarding the THC Device: up until it senses an arc voltage, all of the Step/Dir signals are simply passed along to the Kstep. Once it senses a voltage however it will control the Z axis to go up/down as needed.

*Using this THC seems much more achievable for my skillset than trying to make THC signals look like a quadrature encoder for KFLOP then figuring out how to use those signals (as appears necessary via reading other posts on this forum). Also, I much prefer KMotionCNC to Mach3.

I don't know if you can call the below a wiring diagram, but I think it gets the point across of what I am thinking about doing.

In addition (not in above image) I want a method of bypassing the THC that can be toggled via custom MCode in KMotionCNC. The 2 methods I think would be easiest to do this would be:

1.): put an IO pin triggered relay controlling the torch voltage connection to the THC.
- this is the easiest option, but not preferred because I couldn't view the voltage the THC is reading during the cut.

2.) put IO pin triggered relays controlling the step/dir signals connection to the THC
- this is preferred from a use case standpoint, but I don't know if interrupting the Step/Dir inputs via relay will cause issues with noise or cause the motor to jerk/etc.

[TomKerekes]

Ahh I didn't realize the plasma device switches between pass through and driving the signals.

Regarding method #2 - Yes if using a mechanical relay there may be some glitch steps when switching the signals with a relay. I'm assuming you are thinking like a DPDT relay to switch the KStep Inputs from the plasma device outputs to the KFLOP outputs. I think it should work reliably if the Step signals are low when it is switched. Direction shouldn't matter if it glitches as long as there are no step pulses. KSTEP inputs are basically an LED that needs to be driven high with power to turn on. If the KFLOP output is low and the Plasma output is low then switching back and forth or going open circuit should result in the LED remaining off.

HTH

[a_j_p]

I think I have enough to get started - this will be a slow side project but will report back if more questions/issues

Thanks again.

Also, I have been getting a lot of server 503 errors when trying to respond to this forum. Is that something on my end or just something I have to learn to work around?

[TomKerekes]

Not sure about the 503 errors. They should be temporary. If they persist please let us know.