Improving a CNC plasma cutter with machinekit, BBB and

[Stuart Childs]

Hello all,

TLDR: looking for some advice on what cape/other hardware is best suited for MK + BBB control of a CNC plasma cutter.

Hoping to use MK to deal with THC (torch height control), but depending on how difficult may end up using an external THC box.

Project reqs (I think):

- 3 x stepper control (XX Y, gantry)

- 2 x digital outputs - DC motor up/down for torch height

- 1 x digital input for ohmic sensing of torch height

- 1 x digital output to turn torch on

- 1 x analog input to monitor torch voltage

- 2 x digital inputs for homing switches X Y

Background:

Following a successful conversion of a 3-axis mill to MK control, using BBB with PBX-BB cape, I am looking to move attention to a plasma cutter we have in the workshop. It is new-ish (little used, maybe 5 yrs old) and Quite Chinese. Looks to be a converted router. The pendant 'DSP' controller, is terrible and we are looking to replace the lot with MK, probably a BBB and suitable cape/board.

Does anybody have thoughts or experience on a suitable cape / breakout board, and MK implementation of THC?

It looks like the stepper drivers will be easy enough to interface with for axis movement.

There is some info on EMC controlling plasma cutters, so I'm not asking for specific advice on that for now. I found this link interesting: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Gmoccapy_Plasma

We think there's a few ways of doing it. The THC looks to be the most challenging part.

THC was taken care of by a 'hyperCNC' ! Box that I can't find any info on anywhere. Looks to be a copy of 'hypertherm' brand.

We have replaced the original cheap plasma torch and power supply with a Hypertherm powermax 45 and had it cutting but the controller is so bad. So bad.

Any suggestions / advice appreciated, I will of course keep you all updated with progress, questions and woe (!) once work commences.

Finally apologies if this may be better suited on another list, will change to EMC devs / users if people think necessary.

Best,

Stuart

[Viesturs Lācis]

I have built a plasma with LinuxCNC and Mesa boards and also did a retrofit of existing machine with 2 separate THC sensors - plasma voltage and capacitative ring. 

Here are few comments from me:

1) you most definitely will need a cape for BBB; I suspect that BeBoPr++ or CRAMPS might be most suitable choices, but I am not sure - see 4th point to see why

2) is there any particular reason to use DC motor for Z axis instead of stepper motor? There already is thc component for such a setup.

3) you will need 3 digital inputs for home switches - one for each motor (you did not mention shared home switches)

4) take a look at the Hypertherm plasma source - it should have 0/+10 V analog output for THC (at least Powermax 105 had it). Here comes my doubt about most suitable cape - the one to accept 0/10V analog input wins the deal. If none of them can do it out of box, then I am not able to suggest anything to make it work with existing thermistor inputs. Maybe Bas or Charles can comment on that.

I would get rid of any external THCs as much as possible - either do it all in Machinekit and control all the process there or leave the THC to external controller and switch the DC motor directly from it. Since you want to use 2 separate sensors together, I do not see a way to do it outside Machinekit. Here is how I did it in the retrofit:

1) capacitative ring was "primary" signal, torch voltage was "secondary" signal - if the primary signal told to move up, then it moved up regardless of secondary signal; if the primary signal allowed to move down, then secondary signal was monitored to decide, if it should go up or down or stay at current position;

2) I did that by modifying thc.comp - added one more input for "primary" signal to request upwards movement and then adjusted the code - it was pretty quick and easy even for such non-programmer as me; unfortunately I cannot find thc.comp file in my archive of config backups, so there is nothing I could share

Other than that any of those 2 capes should work - they have 3 powerful outputs, that could directly drive the DC motor or at least switch SSRs.

[Andrew Back]

Hi Viesturs,

I work with Stuart and so I'll try to reply to some of your comments.

On Tuesday, 22 September 2015 19:54:41 UTC+1, Viesturs Lācis wrote:

I have built a plasma with LinuxCNC and Mesa boards and also did a retrofit of existing machine with 2 separate THC sensors - plasma voltage and capacitative ring. 

Here are few comments from me:

1) you most definitely will need a cape for BBB; I suspect that BeBoPr++ or CRAMPS might be most suitable choices, but I am not sure - see 4th point to see why

2) is there any particular reason to use DC motor for Z axis instead of stepper motor? There already is thc component for such a setup.

It already has a 24V DC motor, complete with gearbox and feed screw etc. fitted and cabled up to the cabinet, which was working with the old THC.
 

3) you will need 3 digital inputs for home switches - one for each motor (you did not mention shared home switches)

With the existing THC it did not have a home switch for Z and instead it used ah ohmic sensor (detected the torch tip touching the workpiece).
 

4) take a look at the Hypertherm plasma source - it should have 0/+10 V analog output for THC (at least Powermax 105 had it). Here comes my doubt about most suitable cape - the one to accept 0/10V analog input wins the deal. If none of them can do it out of box, then I am not able to suggest anything to make it work with existing thermistor inputs. Maybe Bas or Charles can comment on that.

Powermax 45 open circuit voltage is 275VDC and THC output is fixed at 50:1 division, giving a max out of 5.5V. This could be divided down further with resistors.
 

I would get rid of any external THCs as much as possible - either do it all in Machinekit and control all the process there or leave the THC to external controller and switch the DC motor directly from it. Since you want to use 2 separate sensors together, I do not see a way to do it outside Machinekit. Here is how I did it in the retrofit:

2 sensors together? Ohmic just detects when the torch is touching the workpiece, following which you raise Z to a preset "initial height setting" (turn motor on for N milliseconds — some calibration required). At least this is how the old Chinese THC — which took the raw arc voltage in on a 9-pin D-sub! — worked.

Regards,

Andrew

[Dave Cole]

--

I'd avoid an ohmic sensor solution to detect the plate.   That is the cheap way out.  Plasma Cam did that for a while and it "sometimes" worked.   A better solution is to use a sliding head so you drop the torch, it makes contact and the pushback from the plate engages a microswitch/prox switch.   I thought the capacitive ring type sensor was usually used on Oxy-Fuel cutting table setups.   There is at least one very well documented THC solution on the LinuxCNC website. 

Dave

---

This email has been checked for viruses by Avast antivirus software. www.avast.com

[Viesturs Lācis]

On Tuesday, September 22, 2015 at 10:37:16 PM UTC+3, Andrew Back wrote:

Hi Viesturs,

I work with Stuart and so I'll try to reply to some of your comments.

On Tuesday, 22 September 2015 19:54:41 UTC+1, Viesturs Lācis wrote:

I have built a plasma with LinuxCNC and Mesa boards and also did a retrofit of existing machine with 2 separate THC sensors - plasma voltage and capacitative ring. 

Here are few comments from me:

1) you most definitely will need a cape for BBB; I suspect that BeBoPr++ or CRAMPS might be most suitable choices, but I am not sure - see 4th point to see why

2) is there any particular reason to use DC motor for Z axis instead of stepper motor? There already is thc component for such a setup.

It already has a 24V DC motor, complete with gearbox and feed screw etc. fitted and cabled up to the cabinet, which was working with the old THC.

Ok, got it. Yes, 3 SSRs would be cheaper than starting to replace mechanics.

 

 

3) you will need 3 digital inputs for home switches - one for each motor (you did not mention shared home switches)

With the existing THC it did not have a home switch for Z and instead it used ah ohmic sensor (detected the torch tip touching the workpiece).

You have gantry, so there are 2 motors for X and 1 motor for Y. At least on this part of world that adds up as 3 motors.

 

 

4) take a look at the Hypertherm plasma source - it should have 0/+10 V analog output for THC (at least Powermax 105 had it). Here comes my doubt about most suitable cape - the one to accept 0/10V analog input wins the deal. If none of them can do it out of box, then I am not able to suggest anything to make it work with existing thermistor inputs. Maybe Bas or Charles can comment on that.

Powermax 45 open circuit voltage is 275VDC and THC output is fixed at 50:1 division, giving a max out of 5.5V. This could be divided down further with resistors.

Hmm, that might make it even easier. I still would like Bas or Charles to comment, how that would work with thermistor inputs.

 

 

I would get rid of any external THCs as much as possible - either do it all in Machinekit and control all the process there or leave the THC to external controller and switch the DC motor directly from it. Since you want to use 2 separate sensors together, I do not see a way to do it outside Machinekit. Here is how I did it in the retrofit:

2 sensors together? Ohmic just detects when the torch is touching the workpiece, following which you raise Z to a preset "initial height setting" (turn motor on for N milliseconds — some calibration required). At least this is how the old Chinese THC — which took the raw arc voltage in on a 9-pin D-sub! — worked.

Ok, got it, I misunderstood. Well, I tend to agree with Dave - there is large probability that the ring will not make a contact and thus will not trigger - some little piece of debris or rust or whatever. Yes, the traditional way to do it is mount the torch on a small slide, which triggers a switch as soon as the torch is lifted up. And then you could use "oneshot" component to calibrate the length of time period, when motor is turned on after the switch is engaged.

[Bas de Bruijn]

On 22 Sep 2015, at 22:45, Viesturs Lācis <viestur...@gmail.com> wrote:

On Tuesday, September 22, 2015 at 10:37:16 PM UTC+3, Andrew Back wrote:

Hi Viesturs,

I work with Stuart and so I'll try to reply to some of your comments.

On Tuesday, 22 September 2015 19:54:41 UTC+1, Viesturs Lācis wrote:

I have built a plasma with LinuxCNC and Mesa boards and also did a retrofit of existing machine with 2 separate THC sensors - plasma voltage and capacitative ring. 

Here are few comments from me:

1) you most definitely will need a cape for BBB; I suspect that BeBoPr++ or CRAMPS might be most suitable choices, but I am not sure - see 4th point to see why

2) is there any particular reason to use DC motor for Z axis instead of stepper motor? There already is thc component for such a setup.

It already has a 24V DC motor, complete with gearbox and feed screw etc. fitted and cabled up to the cabinet, which was working with the old THC.

Ok, got it. Yes, 3 SSRs would be cheaper than starting to replace mechanics.

 

 

3) you will need 3 digital inputs for home switches - one for each motor (you did not mention shared home switches)

With the existing THC it did not have a home switch for Z and instead it used ah ohmic sensor (detected the torch tip touching the workpiece).

You have gantry, so there are 2 motors for X and 1 motor for Y. At least on this part of world that adds up as 3 motors.

 

 

4) take a look at the Hypertherm plasma source - it should have 0/+10 V analog output for THC (at least Powermax 105 had it). Here comes my doubt about most suitable cape - the one to accept 0/10V analog input wins the deal. If none of them can do it out of box, then I am not able to suggest anything to make it work with existing thermistor inputs. Maybe Bas or Charles can comment on that.

Powermax 45 open circuit voltage is 275VDC and THC output is fixed at 50:1 division, giving a max out of 5.5V. This could be divided down further with resistors.

Hmm, that might make it even easier. I still would like Bas or Charles to comment, how that would work with thermistor inputs.

Sorry, I'm mostly a mechanical person who can solder :)

Bas

 

 

I would get rid of any external THCs as much as possible - either do it all in Machinekit and control all the process there or leave the THC to external controller and switch the DC motor directly from it. Since you want to use 2 separate sensors together, I do not see a way to do it outside Machinekit. Here is how I did it in the retrofit:

2 sensors together? Ohmic just detects when the torch is touching the workpiece, following which you raise Z to a preset "initial height setting" (turn motor on for N milliseconds — some calibration required). At least this is how the old Chinese THC — which took the raw arc voltage in on a 9-pin D-sub! — worked.

Ok, got it, I misunderstood. Well, I tend to agree with Dave - there is large probability that the ring will not make a contact and thus will not trigger - some little piece of debris or rust or whatever. Yes, the traditional way to do it is mount the torch on a small slide, which triggers a switch as soon as the torch is lifted up. And then you could use "oneshot" component to calibrate the length of time period, when motor is turned on after the switch is engaged.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at http://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Viesturs Lācis]

On Tuesday, September 22, 2015 at 11:49:29 PM UTC+3, Bas de Bruijn wrote:

Sorry, I'm mostly a mechanical person who can solder :)

Bas

My apologies, I meant Bas Laarhoven - author of BeBoPr++ board. 

[Stuart Childs]

Thanks all for the recommendations. Sadly haven't had lots of time to attend to this refit yet, but happily so - rather than being in a rush!

Taking capes into consideration, and based on the fact that I have had success with the PBX-BB before it was decided to use that cape again. The plan is to fly a wire to an unused analog input pin on the BBB header

I am expecting that I can configure this analogue input to MK using the config.hal file and the pin reference spreadsheet shared by Charles. Any thoughts as to obstacles / something glaringly obvious I might have missed that might cause problems with this?



Regarding home switches, would it be foolish to use just one home switch for the X axis to stop both X-axis motors?


Lastly, the arc voltage output from the Hypertherm Powermax 45 plasma unit is 0-6V, any recommendations on considerations to take into account when converting this to a safe and usable 0-1.8v input to the BBB? Spike / overvoltage protection, opto-isolation, etc? Thinking it should be fairly easy to build a simple circuit to handle this. The question is, just how simple can it be?

Thanks

Stuart

[Charles Steinkuehler]

On 10/27/2015 1:07 PM, Stuart Childs wrote:
> Thanks all for the recommendations. Sadly haven't had lots of time to
> attend to this refit yet, but happily so - rather than being in a rush!
>
> Taking capes into consideration, and based on the fact that I have had
> success with the PBX-BB before it was decided to use that cape again. The
> plan is to fly a wire to an unused analog input pin on the BBB header
>
> I am expecting that I can configure this analogue input to MK using the
> config.hal file and the pin reference spreadsheet shared by Charles. Any
> thoughts as to obstacles / something glaringly obvious I might have missed
> that might cause problems with this?

The BBB analog inputs are *VERY* sensitive and will instantly fry the
CPU if you ever get them over 1.8V! You will want some serious signal
conditioning circuitry between your THC input and the BBB if you don't
use some sort of alternative analog input (perhaps something like an I2C
A/D converter as implemented on the BeBoPr++).

> Regarding home switches, would it be foolish to use just one home switch
> for the X axis to stop both X-axis motors?

Using two switches will allow the homing process to correct for any
racking that occurs. If you have other means to account for the two
motors getting "out of sync", one homing switch should be fine.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Andrew Back]

Hi Charles,

On Tuesday, 27 October 2015 19:27:22 UTC, Charles Steinkuehler wrote:

On 10/27/2015 1:07 PM, Stuart Childs wrote:
> Thanks all for the recommendations. Sadly haven't had lots of time to
> attend to this refit yet, but happily so - rather than being in a rush!
>
> Taking capes into consideration, and based on the fact that I have had
> success with the PBX-BB before it was decided to use that cape again. The
> plan is to fly a wire to an unused analog input pin on the BBB header
>
> I am expecting that I can configure this analogue input to MK using the
> config.hal file and the pin reference spreadsheet shared by Charles. Any
> thoughts as to obstacles / something glaringly obvious I might have missed
> that might cause problems with this?

The BBB analog inputs are *VERY* sensitive and will instantly fry the
CPU if you ever get them over 1.8V!  You will want some serious signal
conditioning circuitry between your THC input and the BBB if you don't
use some sort of alternative analog input (perhaps something like an I2C
A/D converter as implemented on the BeBoPr++).

Not being a fan of fried electronics and free roaming magic smoke, we — I work with Stuart — decided to take on board your advice and use an external ADC for measuring the plasma cutter arc voltage, settling on an MCP3204. It looks as though you cannot use SPI1 without disabling the HDMI (which we need), so we plan to hook it up to SPI0. Once this is done, what additional steps will be required in order to access readings from inside Machinekit? E.g. Is there some devicetree config required?

Regards,

Andrew

[Charles Steinkuehler]

On 11/17/2015 8:59 AM, Andrew Back wrote:
>
> Not being a fan of fried electronics and free roaming magic smoke, we — I
> work with Stuart — decided to take on board your advice and use an external
> ADC for measuring the plasma cutter arc voltage, settling on an MCP3204. It
> looks as though you cannot use SPI1 without disabling the HDMI (which we
> need), so we plan to hook it up to SPI0. Once this is done, what additional
> steps will be required in order to access readings from inside Machinekit?
> E.g. Is there some devicetree config required?

The SPI ports are enabled in the universal cape overlay, so you can
use config-pin to put the pins into SPI mode. There's also a Linux
driver for the MCP320x series available, so it should be fairly
straight-forward to get running in user mode. You can write a C or
Python user-mode HAL component to feed the torch height into HAL.

The user-mode component should work fine as long as you have a fairly
low-bandwidth feedback loop for torch height. If you need high speed
control, you'll have to talk to the SPI hardware directly from HAL.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Andrew Back]

On Tuesday, 17 November 2015 15:11:23 UTC, Charles Steinkuehler wrote:

On 11/17/2015 8:59 AM, Andrew Back wrote:
>
> Not being a fan of fried electronics and free roaming magic smoke, we — I
> work with Stuart — decided to take on board your advice and use an external
> ADC for measuring the plasma cutter arc voltage, settling on an MCP3204. It
> looks as though you cannot use SPI1 without disabling the HDMI (which we
> need), so we plan to hook it up to SPI0. Once this is done, what additional
> steps will be required in order to access readings from inside Machinekit?
> E.g. Is there some devicetree config required?

The SPI ports are enabled in the universal cape overlay, so you can
use config-pin to put the pins into SPI mode.  There's also a Linux
driver for the MCP320x series available, so it should be fairly
straight-forward to get running in user mode.  You can write a C or
Python user-mode HAL component to feed the torch height into HAL.

Ah, this sounds a little more involved than anticipated. Are there good examples for other devices? May be that we can use one as a starting point, or failing which use a device for which someone has already created such a component.
 

The user-mode component should work fine as long as you have a fairly
low-bandwidth feedback loop for torch height.  If you need high speed
control, you'll have to talk to the SPI hardware directly from HAL.

That's good to know. I have seen commercial THC vendors boast about sampling rates for the feedback loop, but hopefully we'll be able to get good enough results with something running in user-mode.

Regards,

Andrew 

[Charles Steinkuehler]

On 11/17/2015 9:39 AM, Andrew Back wrote:
> On Tuesday, 17 November 2015 15:11:23 UTC, Charles Steinkuehler wrote:
>>
>> On 11/17/2015 8:59 AM, Andrew Back wrote:
>>>
>>> Not being a fan of fried electronics and free roaming magic smoke, we —
>> I
>>> work with Stuart — decided to take on board your advice and use an
>> external
>>> ADC for measuring the plasma cutter arc voltage, settling on an MCP3204.
>> It
>>> looks as though you cannot use SPI1 without disabling the HDMI (which we
>>> need), so we plan to hook it up to SPI0. Once this is done, what
>> additional
>>> steps will be required in order to access readings from inside
>> Machinekit?
>>> E.g. Is there some devicetree config required?
>>
>> The SPI ports are enabled in the universal cape overlay, so you can
>> use config-pin to put the pins into SPI mode. There's also a Linux
>> driver for the MCP320x series available, so it should be fairly
>> straight-forward to get running in user mode. You can write a C or
>> Python user-mode HAL component to feed the torch height into HAL.
>
> Ah, this sounds a little more involved than anticipated. Are there good
> examples for other devices? May be that we can use one as a starting point,
> or failing which use a device for which someone has already created such a
> component.

The user-mode HAL component isn't hard if you've got example code for
reading the ADC in Linux via Python. There's an example python script
using the BBB on-chip ADC in the configuration examples:

https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps/hal_temp_bbb.py

...and another one that uses the ADS7828 ADC:

https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps/hal_temp_ads7828.py

>> The user-mode component should work fine as long as you have a fairly
>> low-bandwidth feedback loop for torch height. If you need high speed
>> control, you'll have to talk to the SPI hardware directly from HAL.
>
> That's good to know. I have seen commercial THC vendors boast about
> sampling rates for the feedback loop, but hopefully we'll be able to get
> good enough results with something running in user-mode.

If speed is important, the SPI ADC should run faster than I2C.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Andrew Back]

This is starting to feel like, together with the other config, it could turn out to be relatively involved for someone without a reasonable amount of experience.

In looking for a more tried and tested configuration that integrates THC and does not simply offload this to an external box, it seems that a few folks use the Mesa THCAD board, which converts voltage to frequency and uses an encoder input, albeit with a Mesa I/O solution. I wondered if this might be a better/easier approach, perhaps using a BeagleBone eQEP encoder input. Or perhaps this just means more hardware, but still the same amount of work :o)

Regards,

Andrew

[Charles Steinkuehler]

The Mesa THCAD board should work well with the BeagleBone, which
already has HAL drivers for the hardware eQEP encoder inputs. You
will have to craft some HAL configuration, but shouldn't have to write
any code.

...but just going with Mesa hardware on an x86 system is probably the
path of overall least resistance. I expect to get the Mesa hardware
working with ARM boards at some point, but I still need to get an ARM
system with PCI/PCIe, or maybe get one of the Ethernet Mesa boards.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Viesturs Lācis]

On Wednesday, November 18, 2015 at 12:22:04 AM UTC+2, Andrew Back wrote:

In looking for a more tried and tested configuration that integrates THC and does not simply offload this to an external box, it seems that a few folks use the Mesa THCAD board, which converts voltage to frequency and uses an encoder input, albeit with a Mesa I/O solution. I wondered if this might be a better/easier approach, perhaps using a BeagleBone eQEP encoder input. Or perhaps this just means more hardware, but still the same amount of work :o)

I have used some Mesa THCAD boards, but all of them with Mesa FPGA cards in PC's pci slot. I really like them, "it just works", but I cannot comment on getting encoder input to work on BBB. Just like Charles mentioned, using x86 hardware makes it much easier to set everything up, so IMHO it is a question of priorities - do you want to get the machine working and making sparks in a predictable time frame and can make a little more space in control box for mini-ITX motherboard instead of BBB or do you want it to look very neat and can afford to spend extra time to set it up on BBB.

[Andrew Back]

Indeed, these things so often come down to a trade-off and question of where you want to spend your time.

I must say that I am impressed by the BeagleBone and given our previous experiences using this with a Novamill, we're keen to follow this path. A much simpler solution as far as THC is concerned would be to simply use a Proma or similar external unit, that takes care of sensing the arc voltage and moving Z. However, the hope is to have Machinekit do this, if initially with just very basic THC functionality. So, for sensing we are presently considering hooking up an SPI ADC vs. Mesa THCAD and encoder input.

Something else I've not been able to understand just yet is how to handle the DC brushed motor that is used to lift the torch via a ballscrew. There is no encoder feedback and so I'm wondering 1) how the old Chinese THC electronics did initial height setting, 2) how to configure this in Machekit, e.g. can you say that a certain number of milliseconds of motor on equates to 1mm on Z? Clearly scope for error here, but can't see how else you would do IHS, given that this is pre-plasma firing and so you have no arc voltage feedback to use in setting distance from workpiece.

Cheers,

Andrew

[Viesturs Lācis]

On Wednesday, November 18, 2015 at 1:23:18 PM UTC+2, Andrew Back wrote:

Something else I've not been able to understand just yet is how to handle the DC brushed motor that is used to lift the torch via a ballscrew. There is no encoder feedback and so I'm wondering 1) how the old Chinese THC electronics did initial height setting, 2) how to configure this in Machekit, e.g. can you say that a certain number of milliseconds of motor on equates to 1mm on Z? Clearly scope for error here, but can't see how else you would do IHS, given that this is pre-plasma firing and so you have no arc voltage feedback to use in setting distance from workpiece.

I had a "floating head" setup, where the torch was mounted on a separate vertical linear rail and was held down by 2 springs against hard stop - it was possible to move the torch upwards and it tripped a switch, when that happened. It was used to sense the material surface - move down until switch is tripped, then back up to pierce height (I even had adjusted SheetCAM postprocessor to insert these lines right in the g-code). In your case, when there is no feedback from motor, I do agree that time as the basic calibration unit seams most reasonable approach. I mean, yes, translate required distance of travel into particular time period, when the motor has to be turning in particular direction. The best way to do it seems M62/M63 or M64/M65 commands (or whatever else you are using to move the Z motor) with G4 Pxx inbetween.

[Daren Schwenke]

As for your 0-10v ADC problem..

Use a voltage divider, and tie three switching diodes in series across your ADC input.

Each diode will give you a .6v drop, so combined you'll limit your input to 1.8v.  Test your diodes to ensure they each provide the appropriate drop as they vary a bit, but .6v is the average.

For the voltage divider, put a 10k resistor across your ADC input and feed it through a 68k resistor.

[Andrew Back]

Thanks for the advice, it's much appreciated! Although I'm still struggling to work out what this would translate to in hal config. Here is the file for our mill:

  https://github.com/abopen/cnc-configs/blob/master/Novamill/Novamill0.hal

So with the plasma we'd also have a PRU pwmgen configured in the ini file, but not sure what we'd need to have in the Z axis section of the hal config. The pwmgen would need to take a positive float to raise Z and negative to lower, but what hal config would we use to keep track of the position, mapping from e.g. mm to ms motor on time, to be able to jog Z from within Axis.

Regards,

Andrew

[Michael Torrie]

On 09/22/2015 10:57 AM, Stuart Childs wrote:
>
>
> Hello all,
>
>

> *TLDR: looking for some advice on what cape/other hardware is best suited
> for MK + BBB control of a CNC plasma cutter.*

>
>
> Hoping to use MK to deal with THC (torch height control), but depending on
> how difficult may end up using an external THC box.

Interesting project, and good information on this thread. I'm following
this closely as I'm interested in refitting our good old mini torchmate
CNC machine, and adding THC to it.

Something I am considering doing, rather than mess with my own voltage
divider and THC loop in MK, is to use the Proma THC system in
conjunction with MK. The Proma system takes arc voltage into it and
generates simple up/down signals that can feed back into MK. This has
the advantage of being simple and electrically safe, and MK can ignore
the signals when making a sharp turn. However since MK is not aware of
voltage, it won't necessarily prevent the head from plunging when it
goes off the edge of the metal, though maybe there are ways of dealing
with that in MK. Perhaps someone can comment on this technique.

Please keep the list posted on how your project comes together.

[Klemen Zhivko]

I am in doubt how to wire Hypertherm Powermax45 xp plasma with CPC port, so I decided to post picture with connections here. This is somehow related to previous posts so I hope author of main topic will pardon me for hijacking.

The main problem seems to be for me that voltage levels are not clearly stated in plasma manual and I do not want to ruin some board with two high voltage. They mention dry contact in manual - so actually I have difficulty to know should I use relay or not - or how connection should be made.

The controller that should trigger or read signals from CPC port is BeagleBone black that runs MK - actually it is equipped with CRAMPS hat that is 5V level compatible (reprap.org/wiki/CRAMPS).

On picture below you will see that for:
1) thc voltage I use mesa thcad 10V card
2) for plasma start signal I use 5V relay
3) for transfer signal - I plan to directly connect THC signal to cramps signal - this is the point that worries me most, but I am not sure will in case of transfer plasma box pull this line to gnd and when signal is not triggered it will be left floating so it will be pulled to 5V on cramps board side?

Is my wiring OK? Will P_503 pin header on CRAMPS be right place for this 3 signals to be brought in?

I hope picture could let you know how do I plan to connect it and I am opened to suggestions and/or corrections.

regards

Dne sobota, 21. november 2015 06.02.10 UTC+1 je oseba Michael Torrie napisala:

[Klemen Zhivko]

OK got answered on linuxcnc forum that:

"

For CPC 12 -14 they have relay in torch that can contact 120VAC, 1A, but generally speaking I can put 5V, 50ma to this 12 pin of cpc (instead so huge 120VAC, 1A), and connect 14 pin to my digital in (5v) on board.
When relay triggers in plasma torch (14 should go to 5V) and I measure this 14 line as 5V on my digital input pin on 5V compatible linuxcnc computer.

"

So here I attach adapted picture for anybody having same concerns.

Now I would "only" like to get confirmation from @cdsteinkuhler that using P_503 port, pins

P503_1 as 5V digital IN as for ENCODER from 5V signal of (thcad 10V)

P503_2 as 5V digital OUT for PLASMA START

P503_3 as 5V digital IN for for TRANSFER (cnc start moving)

is OK.

Dne četrtek, 06. oktober 2016 23.46.20 UTC+2 je oseba Klemen Zhivko napisala:

[Klemen Živkovič]

Oh I see on cramps schematics (http://reprap.org/wiki/File:CRAMPS.v2.1.sch.pdf) that P503 signals are all pulled up to 5V so for transfer it would be better to use GND instead CRAMPS_5V.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---

You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/fAXkekPmHR8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.

[Charles Steinkuehler]

On 10/7/2016 3:28 AM, Klemen Zhivko wrote:
> OK got answered on linuxcnc forum that:
>
> "
> For CPC 12 -14 they have relay in torch that can contact 120VAC, 1A, but
> generally speaking I can put 5V, 50ma to this 12 pin of cpc (instead so
> huge 120VAC, 1A), and connect 14 pin to my digital in (5v) on board.
> When relay triggers in plasma torch (14 should go to 5V) and I measure this
> 14 line as 5V on my digital input pin on 5V compatible linuxcnc computer.
> "
> So here I attach adapted picture for anybody having same concerns.
>
> Now I would "only" like to get confirmation from @cdsteinkuhler that using
> P_503 port, pins
> P503_1 as 5V digital IN as for ENCODER from 5V signal of (thcad 10V)

This is fine.

> P503_2 as 5V digital OUT for PLASMA START

This might not work. These pins are protected against 5V levels, but
only have the drive capability of the BBB I/O pin (which is 3.3V and a
few mA). If this is not a high-speed signal, I would suggest using one
of the low-power FET outputs. These are "open-drain" style outputs and
can handle voltages up to 12V.

> P503_3 as 5V digital IN for for TRANSFER (cnc start moving)
> is OK.

This is fine.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Charles Steinkuehler]

On 10/7/2016 3:45 AM, Klemen Živkovič wrote:
> Oh I see on cramps schematics (
> http://reprap.org/wiki/File:CRAMPS.v2.1.sch.pdf) that P503 signals are all
> pulled up to 5V so for transfer it would be better to use GND instead
> CRAMPS_5V.

Sorry, I don't really understand the question.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Klemen Zhivko]

Question was related to wiring schema I plan to use - picture available on this link: "https://raw.githubusercontent.com/zhivko/PipeCutter/master/screenshots/PLASMA_WIREUP.jpg"
more precisely about how to connect transfer signal from torch to cramps hat.
1) CPC_14 and CPC_12 are dry relay contact in hypertherm plasma that are contacted when CNC needs to do "motion"

2) I plan to use P503_3 pin on cramps

3) first I thought I need to use 5V connected on CPC_14 but then I noticed P503_3 is pulled up to 5V

4) this mad me think oh P503_3 is already on 5V so it will make no difference if 5V will be brought and PIN will not be altered in this case

5) I decided to use GND connected on CPC_14 (I corrected schema in upper link accordingly).

Regarding this:

"

This might not work.  These pins are protected against 5V levels, but 
only have the drive capability of the BBB I/O pin (which is 3.3V and a 
few mA).  If this is not a high-speed signal, I would suggest using one 
of the low-power FET outputs.  These are "open-drain" style outputs and 
can handle voltages up to 12V. 

"

I use 3.3V relay and I think it has some FET embedded on it. Something like:

http://www.ebay.com/itm/DC-3V-3-3V-Relay-High-Level-Driver-Module-optocouple-Relay-Module-for-Arduino-/331502222842?hash=item4d2f127dfa:g:fgYAAOSwX~dWqZEx

So I cross my fingers that BBB with few mA driving capability would be able to run it.

Dne petek, 07. oktober 2016 18.42.36 UTC+2 je oseba Charles Steinkuehler napisala:

[Klemen Zhivko]

It would be nice and maybe somebody already have thc configuration so I could reduce number of trial/error iterations.
Does anybody know for working thc comp with linuxcnc/machinekit and possibly on BBB so I could check configuration?

I am looking into THC comp (machinekit\src\hal\i_components\thc.icomp)

I see there are few parameters available to influence THC comp operation - namely:

// Parameters

pin io float vel_scale "The scale to convert the Velocity signal to Volts";

pin io float scale_offset "The offset of the velocity input at 0 volts";

pin io float velocity_tol "The deviation percent from planned velocity";

pin io float voltage_tol "The deviation of Tip Voltage before correction takes place";

pin io float correction_vel "The amount of change in user units per period to move Z to correct"; 

So I plan to instantiate thc comp within my hal with:

newinst thc thc0 vel_scale=0.00037866834  scale_offset=119000 velocity_tol=3 voltage_tol=2 correction_vel=0.0001

But what would be the values of those parameters?

Also for using thcad 10V I would need encoder and it seems I would need to use:

http://www.machinekit.io/docs/drivers/hal_arm335xQEP/

so:

loadrt hal_arm335xQEP encoders=eQEP0

but where do i specify what are source pins that encoder is counting them in component?

I was already checking:

https://github.com/cdsteinkuehler/machine-configs/blob/master/motorctrl/hardware.hal

[Klemen Zhivko]

From example posted by Charles (https://github.com/cdsteinkuehler/machine-configs/blob/master/motorctrl/hardware.hal), I see:

# 9/25  strobe - not connected

# 9/27  B in  - Hall sensor pin A - white

# 9/41  index - not connected

# 9/42  A in  - Hall sensor pin B - yellow

Does this means encoder expects wires on those pins and I cannot change that anyhow? I wonder if they are available on Cramps hat?

in Cramps schematics:

925 = LED
927 = FET3

941 = AIN0

942 = SPI_CS1

I planned to use:

CRAMPS_P503_2 MISO P929 ...  for thc voltage from mesa thc 10v - needs to go to hal_arm335xQEP encoder

CRAMPS_P503_4 SCK   P931 ...  plasma start
CRAMPS_P503_6 MOSI P930 ...  transfer start CNC machine motion

So can I wire somehow this P929 to encoder? And also I obviously have only one channel A from MESA THC10V, instead A,B as in Charles sample.

Dne četrtek, 27. oktober 2016 12.24.08 UTC+2 je oseba Klemen Zhivko napisala:

[Charles Steinkuehler]

On 10/27/2016 7:28 AM, Klemen Zhivko wrote:
> From example posted by Charles
> (https://github.com/cdsteinkuehler/machine-configs/blob/master/motorctrl/hardware.hal

> <https://github.com/cdsteinkuehler/machine-configs/blob/master/motorctrl/hardware.hal>),

> I see:
>
> # 9/25 strobe - not connected
> # 9/27 B in - Hall sensor pin A - white
> # 9/41 index - not connected
> # 9/42 A in - Hall sensor pin B - yellow
>
> Does this means encoder expects wires on those pins and I cannot change that
> anyhow?

If you are using the hardware encoder modules (eQEP), they have very
specific pins that must be used.

> I wonder if they are available on Cramps hat?

The CRAMPS board was not designed to work with encoders, so you will
have to do some soldering (see the previous thread).

Another option would be to use a PRU based encoder. This also has pin
restrictions, but you can use any PRU dedicated input pin, some of
which are available on the CRAMPS SPI expansion header and are already
protected against 5V signals.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Klemen Živkovič]

OK I will go then for PRU encoder.

I tried to find example in 
https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/CRAMPS/CRAMPS.hal
but I could not find it and I cannot see how it should be configured.

Any example?

[Charles Steinkuehler]

On 10/27/2016 9:46 AM, Klemen Živkovič wrote:
> OK I will go then for PRU encoder.
> I tried to find example in
> https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/CRAMPS/CRAMPS.hal
> but I could not find it and I cannot see how it should be configured.
>
> Any example?

I know some people have used the PRU encoders, but I'm not sure there
are any available example configurations. The man page describes how
the PRU encoder logic works:

http://www.machinekit.io/docs/man/man9/hal_pru_generic/

Note that you have to use PRU direct input pins, and set them to PRU
input mode (typically via setup.sh) prior to running the
hal_pru_generic driver.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Klemen Zhivko]

OK I did some tests in my simulation environment, while still waiting for hypertherm45xp that should arrive end of November.

My ini configurations are at: https://github.com/zhivko/machinekit/tree/master/myini)

Instead velocity from thcad 10V, I feeded velocity from my rand component that actualy generates sinusoidal simulated plasma voltage, and I can see THC reacts to this altering

z_pos out (https://github.com/zhivko/machinekit/blob/master/mycomponents/mythc.comp#L142)

this is than linked in hal to z-axis movements via

hpg.stepgen.02.position-cmd (https://github.com/zhivko/machinekit/blob/master/myini/THC.hal#L85)

  

I can see in halscope that hpg.stepgen.02.position-cmd is moving up or down, because actual voltage is changing sinusoidal around requred 120V, but I cannot visualize this movements via my simulator because I take Z data from mkwrapper message with type MT_EMCSTAT_INCREMENTAL_UPDATE like

z = contReturned.getEmcStatusMotion().getActualPosition().getZ();

  

To get actual z position (with thc in place) it seems it would be more appropriate read pin hpg.stepgen.02.position-cmd? Would that be correct approach or any other better idea?

[Klemen Zhivko]

Hey guys,

Hypertherm 45Xp, arrived so now I need to connect everything together.

I started with fritzing scheme and I lost few days creating fritzing elements for:

- cramps hat

- thcad10V

- 3.3V relays

- closed loop stepper driver leadshine ESD808

So if anybody wants this parts in fritzing I made contact me and I will gladly share them ;).

From all this here is 1st draft version of connection diagram for my bbb - cramps - plasma cutter setup.

If somebody sees mistake let me know.

My open question is: thcad10V has shield pin, and I think (but not sure) CPC cable from hypertherm must be shielded, but shield pin in CPC port is not available so I plan to leave shield pin on thcad10v floating (unconnected) - is this OK?.

my current machinekit config is in:

https://github.com/zhivko/machinekit/tree/master/myini

and custom components in

https://github.com/zhivko/machinekit/tree/master/mycomponents

Dne sreda, 16. november 2016 12.05.28 UTC+1 je oseba Klemen Zhivko napisala:

[Klemen Zhivko]

Ok I managed to made first cuts with my setup. If anybody is interested here is video of first cuts:

https://goo.gl/photos/mhikDQKHRhVWH2n16

Current cut is with thc on - however I still need to confirm thc works as it should. I needed to use 1/128 frequency divider on mesa thcad10V to be able to count mesa velocity signal on beaglebone.

I still miss good air compressor - the one I own currently seems to lack power this is why I couldn't make whole cut.

There is quite some dross produced on other side of cutting surface - but this can probably solved with faster movements. Hypertherm plasma cutting charts are there, but only for fastest possible speeds, but I want to run on lower speeds (I do not want to introduce more shaking to cutting process).

It seems that next steps are to try different speeds - for this reason I modified my UI to allow settings different speeds (marked with red in this video: https://goo.gl/photos/JcBEzWAyDH8Tft1L7)

On this occasion I would like to express big gratitude to machinekit and lcnc comunity, from which I got all necessary information for making sw for operating machinekit and this BIG machine.

Especially big thanks goes to next guys:

Michael Haberler

Alexander Rösler

Charles Steinkuhler

and

Sarah Armstrong

regards

Dne nedelja, 04. december 2016 12.34.28 UTC+1 je oseba Klemen Zhivko napisala:

[Bas de Bruijn]

Hi Klemen,

Very impressive!

Keep up the work

Cheers,

Bas

--

website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---

You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.

[Daren Schwenke]

Looking good.  

I like seeing when problems turn into solutions through persistence.  :)

On Tuesday, September 22, 2015 at 12:57:08 PM UTC-4, Stuart Childs wrote:

Hello all,

TLDR: looking for some advice on what cape/other hardware is best suited for MK + BBB control of a CNC plasma cutter.

Hoping to use MK to deal with THC (torch height control), but depending on how difficult may end up using an external THC box.

[IonicBasher]

Hello everyone I have been running my CNC router on a cramps board reliably for awhile now. 

I am cnc routing with it and have also 3D printed using a removable heated bed.

 Being able to switch to different config files has really been great.

I am now looking to adapt a plasma torch and a removable water table onto the cnc machine.

I have a few questions.

I see that the configuration here provided by Klemen uses a software THC component?

On my CNC I have open loop stepper motors driving all axis, but this configuration uses closed loop servos, will I have problems with configuration?

Specifically does it use the encoders position for the z axis for THC use? 

You also use rotary axes for turning but I have a cartesian machine. Would using my standard .ini raise any issues?

Thanks

[Rob M]

HI,

Hope I'm not too late.

I have designed a cape\daughter board concept

https://groups.google.com/forum/#!topic/machinekit/Ng-LrXFuVE8

https://github.com/ozzyrob/pp_cape
https://github.com/ozzyrob/pp_bob_output
https://github.com/ozzyrob/pp_bob_input

The cape logically groups the digital signals and brings out the analogue signals as well as Ic2. The 2 daughter boards provide 5v/3.v level translation, one board provides:
 8xDigital outputs for STEP-DIR (connect to PRU pins)
 5xDigital Inputs
 4xDigital Outputs

The second board provides.
 8xDigital Inputs, two of which are connected to eQEP2A & eQEP2B
 5xDigital Inputs
 4xDigital Outputs

Also an additional output the controls the input & output buffers. Everything is designed using through hole components and the daughter boards are sized to fit 72mm DIN mount PCB holders.
 I have a set of 3 boards I can give away if you are interested, drop us a email. I have also put together a PyVCP test panel to test the initial operation.

Cheers
Rob

[Klemen Živkovič]

Yes it is software thc. Check my repo https://github.com/zhivko/machinekit.

In my config closed loop stays between stepper and stepper driver. Encoder signals of loop are not forwarded to beaglebone and mk in any way, so it is practically same configuration as yours.

regards

Klemen

--

website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---

You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/fAXkekPmHR8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+unsubscribe@googlegroups.com.