Page 2 of 2

Re: Terje's buildlog

PostPosted: Sun Apr 19, 2015 12:39 pm
by terjeio
Thanks for nice comments, it helps tremendously to have access to the wealth of information provided by all the previous builders.
My CNC mill is also a vital tool to have when fabricating parts.

I got my prototype controller PCB back from China a few days back, and I have now ported over my test program and the core functions are all up and running.
Next step will be to let Mach 3 gain control of the machine and then implement PPI control for cutting.
I will then try to implement a plugin for Mach3 - for controlling PPI, power and maybe even share current position with my controller...

Re: Terje's buildlog

PostPosted: Sun May 03, 2015 3:36 pm
by terjeio
Finally got Mach3 working, some problems with the BOB as my CPLD-counters were counting more or less randomly when fed with pulses from Mach3. A pair of Schmitt-triggers cured that problem. PPI-control is a must, it gives very fine control of both engraving and cuts - however I need to add preset support to my control software as there are to many combinations to keep track of... I have used dirktheengs code as a starting point for Mach3 PPI-control but had to convert it to integer math as MSP430 is too slow to handle floating point in real time - I think any rounding errors due to this does not affect the final result that much. So, I have a useable machine now :D

Re: Terje's buildlog

PostPosted: Tue Jun 21, 2016 1:33 pm
by terjeio
New controller made, have gone 32-bit - can now do a lot more fancy coding...

IMG_7888.JPG
New board


IMG_7890.JPG
Piggy back on Chinese breakout board (for Mach 3)


IMG_7891.JPG
(Nearly) same connections as Chinese breakout


IMG_7893.JPG
OLED display in front panel


Hardware:

1. Main board

3-axis motion controller for four motors, Y-output is switchable between two motors (Y or A)

Texas Instruments (TI) Tiva TM4C123GH6PM as main processor - ARM Cortex M4F: 80 MHz, 256 KB flash, 32 KB SRAM, 2KB EEPROM, ROM-based library (TivaWare)

TI MSP430G2553 MCU with two CPLDs provides PPI-control for lasers, controlled by main processor via I2C.

Isolated input via USB-to-serial (FT232RL) or direct serial provided by ADUM1402, optionally USB directly (not isolated).

I2C bus made available for add-on boards.

On board regulator for +5V, 6.5 - 36 V supply range (TRACO TSR 1-2450)

2. Relay control board

via I2C - for air assist, coolant pump and fans, 4 channel board made.

3. Front panel boards

Control via I2C, for display and buttons. Board made with OLED display for status, 13 buttons for power, relay control, laser test fire and axis jogging.

Firmware/software:

Proprietary code for engraving, supporting desktop application written in C# for Windows.

Mach3 option via piggyback to common paralell port breakout board, supported in proprietary code (mode select).
PPI mode available, controlled by desktop application.

GRBL option in the making, code has been ported from latest version - must be integrated with proprietary code.
My plan is to make a HAL (Hardware Abstraction Layer) for GRBL, and change it into a library.

Re: Terje's buildlog

PostPosted: Mon Jul 04, 2016 7:11 am
by terjeio
Ready to try grayscale (3D) engraving - 128 levels implemented. :)

gray.png
Updated UI for grayscale engraving

Re: Terje's buildlog

PostPosted: Wed Jul 06, 2016 9:13 am
by terjeio
First attempt at grayscale/3D engraving were successful in that the software and hardware works as expected, only some minor software issues to be corrected.
However, I now face the problem of laser supply/laser tube linearity - the combo is not linear, that is the control voltage/laser output power has a nonlinear relationship.

My controller has a 12 bit DAC for adjusting laser power, which translates to 4096 discrete levels, however about half is lost due to the fact that the usable range is about 1.0 - 2.5V from a possible output of 0 - 3.3V. The output could be corrected for by adding an op-amp to set gain/offset, however I have opted for a software solution for now.

The software solution is based on a lookup table mapping percentage power (combined with an offset) to set control voltage. This has the bonus of beeing able to use a table that corrects for any linearity issues. Since I do not own a power meter I have run into the problem of creating such a table, I can of course try to create one by trial and error - but maybe someone else has created one that could be used as a starting point?

Since the controller has 2Kb of EEPROM I have implemented functionality to download a profile from the desktop application - no need to recompile new firmware.

IMG_7894.JPG
From the very first attempt at 3D engraving

Re: Terje's buildlog

PostPosted: Thu Jul 07, 2016 12:32 pm
by terjeio
Some progress, and got a crazy(?) idea about measuring (relative) power output for calibration - maybe a micrometer clock can be used? Plot a 3D grayscale in acrylic and measure depth of each level...

IMG_7896.JPG
3D engraving in acrylic - laying flat...


IMG_7898.JPG
... and held against light from the gray sky here today, Einstein is engraved @150dpi, cat @300dpi. 300dpi is minimum I think, at 150dpi each line is clearly visible.

Re: Terje's buildlog

PostPosted: Thu Jul 07, 2016 11:18 pm
by cvoinescu
You could get an approximate relative measure of power by engraving a series of lines, next to each other, alternating between full power at high speed, and various guesses at what should be half power at half that speed; then compare adjacent lines, pick the closest match, and call that 50% power. Continue the same way for a few more data points, especially at the low-power end of the curve.

Re: Terje's buildlog

PostPosted: Sun May 21, 2017 6:24 pm
by terjeio
I finally got around to integrate Grbl (v1.1) into my controller code, I have HALified Grbl in my port and made it into a library to achieve that. The driver layer supports custom M-codes for controlling the PPI-mode parameters, integration with front panel buttons (including jogging) and display. My desktop application has gained a gcode streamer tab supporting the Grbl streaming protocol and has support for 3-key rollover jogging via the PC keyboard. Some fine tuning remains for the UI, I need to use it a bit to find out what features to add...

gcode.png
Grbl (gcode) tab in action

Re: Terje's buildlog

PostPosted: Wed Sep 27, 2017 12:39 am
by terjeio
As a coding excercise I have made a PSoC5 PPI module - a USD 10 CY8CKIT-059 development board is all that is needed, no external electronics. Step counters are implemented using PSoC UDBs - which are similar to FPGAs. Note that I am not going to use this design myself since my controller has PPI handling implemented using CPLDs.

The solution is available from my Github account.

Terje