Base64 coding problem on trunkey Marlin for raster engravings

As the title suggest I found a problem with the modifications I made to the Marlin firmware.
I now use power settings from 0-10000 instead of 0-255 (which was limited to 100 anyway).
Everything works as planned now, especially the 8bit engraving.
However when I wanted to compare raster vs 8bit I did not get any output in raster mode.
This had me stubled at first as the raster info is read from the pixel lines in values from 0-255 and then base64 encoded.
But no matter the power settings or manual attempt in raster mode there is no laser.
Display states the set power but now firing at all.
After more firmware digging I found that in raster mode no manual firing or testfiring works without a movement encoded in base64
While digging I found this line in marlin_main.cpp:

if (code_seen('D')) laser.raster_num_pixels = base64_decode(laser.raster_data, &cmdbuffer[bufindr][strchr_pointer - cmdbuffer[bufindr] + 1], laser.raster_raw_length);


Which corresponds to some calcultaions in planner.cpp:

for (int i = 0; i < LASER_MAX_RASTER_LINE; i++) {
            
            //Scale the image intensity based on the raster power.
			//100% power on a pixel basis is 255, convert back to 255 = 100.
			
			//[stackoverflow.com]
			int OldRange, NewRange;
			float NewValue;
			OldRange = (255 - 0);
			NewRange = (laser.rasterlaserpower - 750); //7% power on my unit outputs hardly any noticable burn at F3000 on paper, so adjust the raster contrast based off 750 being the lower. 750 still produces burns at slower feed rates, but getting less power than this isn't typically needed at slow feed rates.
			NewValue = (float)(((((float)laser.raster_data - 0) * NewRange) / OldRange) + 750);
			
			//If less than 750, turn off the laser tube.
			if(NewValue == 750) 
				NewValue = 0;
			
            block->laser_raster_data = NewValue; 
        }

From what I understand after reading up on the base64 stuff for Arduino it only works with bytes, so 255 is the max it can handle.
Since the laser_raster_data is now in the range from 0-10000 I assume here is the culprit for not getting any power out of the laser.
Is my understanding corrent and if so - how can use the higher values with this base64 encoding stuff?

I like the idea of having far less data and higher speeds and would love to:
1. get the raster engraving working again with the changed power levels.
2. find a way to use this base64 encoding for 8bit engravings as well.
But of course 2 will be impossible to realise if I can't get 1 to work
Any help on this is highly appreciated here
And yes, I checked the raster works fine if I revert the power setting back to the old range.

Edited 1 time(s). Last edit at 03/23/2016 07:36PM by Downunder35m.

Should be

block->laser_raster_data[i] = NewValue;

but I guess the "i" was stolen by the text formatting.

If you change the range of laser_raster_data you need to check in the stepper interrupt routine that
there is no overflow, and also in laser_fire().
You can use debug printouts with SERIAL_PRINTLN or something on these lines.
There will be a lot of output, but a few pixels long black/white G7 line should be possible to debug.
There are basically only four places to look at, in Marlin_main around the G7, in planner.cpp
which you refer to, the stepper interrupt routine and in laser.cpp.

I haven't followed your work if you have reported about it here. I just jumped in, sorry if I missed
something obvious.

Out of curiosity, why don't you find the range 0-255 sufficient?

Thanks, will look into the stepper routine as this is one I did not check before.
The 255 range is actually limited to 100 to reflect the original 100% settings I guess, or to protect the laser tube.
So in reality you can only get quite big steps for the power increase.
Add just 1 to the power and paper that did not even get dark burns right through.
For 8bit engraving I needed a better control range and as it turns out it works fine.
Just now I noticed that the base64 stuff no longer works with the new levels.

Good point. I see, yes, it is limited to 0-100 in laser_fire(int), and the int type reduces the resolution.
The range 0-255 gets mapped to 0-100 with only 100 steps.
Unless the pwm duty cycle resolution is increased, there is anyway a limit 0-255 in the pwm.
I think what I will do is to make a laser_fire_byte(uint8_t) that uses the range 0-255.
and use that for the raster data.
Thanks for pointing this out.

I already looked into some other options to increase the level of control over the power settings.
The final stuff is done through an analogwrite on the firing pin - and there again still limited to 255 steps.
So even if change the laser fire byte in the end it is still just 255
Difference with my approch was to increase the resolution of the intensity.
As neither Marlin nor Arduino can handle decimals for analog write functions it was the easiest way to get more precision.
It's not the signal, it is the calculation that counts in this case.
Sadly the entire raster stuff is messed up if done like this.
Unless I missed a simpler way I guess it is back to the drawing board.
Just too bad that Turnkey seems to have abandoned all support on the project.

I think that if you set intensity to 255 in the M649 then the whole range 0-255 will be used.

The M649 only specifies the laser settings.
Setting S to 255 here will set the power for the G7 to 255.
The real culprit here is the base64 stuff that can't really handle values over 255 - or I am just blind again.
But if the base64 decoding can't resolve the intensity values above 255 the whole calculation is off and returns zero for the power level.

Yes the G7 power level will be 255 (laser.rasterlaserpower specifically), and in the code in planner.cpp that you refer to in the first post here,
the raster data will not be mapped to 0-100 but to 0-255, and you would get that range to analogWrite. If I understood it right.

The way base64 is used, yes it only handles 8-bit bytes. But base64 only encodes/decodes whatever is put into it.
You can arrange to have a 16-bit value for the grayscale and put that into base64 to form a G7 line.
And in Marlin you need to form a 16-bit value from the base64. It is doable, requires modifications
both in the G-code generator and in Marlin.

... I've recently tested the DAC's of the ArduinoDue setting the resolution to 12 Bits - no problem to output analogue values in 4096 steps from 0 to 3.3V (or 0 to 5V with our "shield").

This give me a fine "saw-tooth"-curve on the oszilloscope:

...
// pinMode(ANA_Out, OUTPUT);
pinMode(DAC0, OUTPUT);
analogWriteResolution(12);
}

void loop() {
// put your main code here, to run repeatedly:
value = value + astep;
if (value<1){
astep=1;
digitalWrite(WDOG,HIGH);
}
if (value>4094){
astep=-1;
digitalWrite(WDOG,LOW);
}
analogWrite(DAC0,value);
delayMicroseconds(50);
}

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Intersting concept but I see no real chance to implement this into Marlin with success.
Marlin is messy enough as it is and I don't have the right shield for it I am afraid.
Still I like it and will check if I can get some working ideas out of it - thanks for that!

@Falwty99: I looked into the possible mods that I can understand.
The funny thing is that even some basic changes to the rasterlaserpower in forms of added calculations before the stuff in planner.cpp will make it go bad.
For axample I only adjusted the power levels to be in the high range but devided the rasterlaserpower before processing by the same range.
No matter if integer or float the result is that nothing at all is engraved.
The laser moves correctly left and right but with no power.
Getting the feeling that I miss another check for the laserrasterpower somewhere.
It makes no sense that with the same values as before, just calculated slightly different, nothing will be rastered.
Power level 16 as standard works fine, using 1600 and divide by 100 and nothing works - makes no sense to me, so I might have to do some more code works here...



Edit:
I think I am circling in on the problem.
The base64 encoding works with strings, not numbers!
That means the lenght of encoded data must match the specified length for it.
The laser firing works about like this:
The lenght o the laser line is checked and the laser fired to match exactly that lenght, from a single pixel to a full line.
The encoded data relies on an input level from 0-255 for the decoding of the power settings.
However, in the Turnkey firmware the time for the laser firing as determined in a whole different section of the code.
By changing the intensity level within the 0-100 range all works as expected.
But increasing this range does two things for the raster decoding (if I understand the code correctl):
A ) It changes the power level calculations to have more precision - which is good in theory.
B ) It also changes they way the laser firing length is calculated through the base64 stuff - and that is really bad.

So far I only see one option for a fix
Change the raster encoding so the pixel values are only used to set a basic power range for the laser depending on the settings for the level encoding.
E.g.: 0 - 100 for orignal, 0 - 255 to keep the full range of grey levels.
This would be in the Inkscape plugin.
For the firmware itself it should correspond to these changes:
Change the base64 decoding so the pixel data is converted back to a line as it is now and do the addressing of the power levels in another step before sending the final code to the machine.
Problem here is that this would require massive code changes as the entire raster section needs to change, same for all other base64 calculations in the code that use the raster date as an input.

In the plugin the code is generated purely based on the pixel value and the power level is just handed over so to say.
In the firmware this combined to something that can be lasered while changing the pixel value based on the set power levels.
Can't really find enough helpful info on the base64 stuff to make more sense out of it, more reading required LOL

If I understand the sample code from the library correct than I see why it does not work in the firmware.

 // decoding
  char input2[] = "Zm9vYmFy";
  int input2Len = sizeof(input2);
  
  int decodedLen = base64_dec_len(input2, input2Len);
  char decoded[decodedLen];
  
  base64_decode(decoded, input2, input2Len);
  
  Serial.print(input2); Serial.print(" = "); Serial.println(decoded);

In Marlin_main.cpp where the decoding happens the laser.raster_data used for the base64 decoding, which originates from the changes to the laser.rasterlaserpower.
So anything between 0 and 255 will still return a usable code but values above 255 mess up the pixel calculations and no power goes to the laser.
Our power levels changes the output buffer for the base64 encoding if I get it correctly.
So the question remains how to do this differently with higher power levels.
Looked into the high/low bytes thing but not sure if that is of any help with the buffer lenght
Somehow I fail to see why the laser power was implemented into the encoding like this.
There should be an easier way to set the power for a raster engraving outside the base64 stuff.

Edited 3 time(s). Last edit at 03/25/2016 09:36PM by Downunder35m.

Sometimes you just can't see the forest because all the trees are blocking your view
I focused on the base64 problem and the related calculations to get the raster engraving working again with the higher power levels.
While in fact all that's needed was a tiny change in marlin_main.cpp.
Had to sacrifice the higher power resolution for raster mode but since it is on and off only all that's left now is bit of finetuning.
Cleanup for some moves from Image2Gcode resulting in laser burns where there should be none, implementing the new power levels and other changes into the display sections ...
But that is now only simple work, the hard part is finally done

Tonight I will create some code for a video showing vector, raster and 8bit encoding done in one single machine run.
Assuming this works out as planned I guess it is time to add the stuff on Github or similar so that everyone can benefit and set it up for his/her system.
Due to the postings about the higher performance of the DUE I am already thinking of getting one though LOOOOL

Edit:
Now I am starting to go nuts here...
I can change the raster power and I can change the normal power but I can not change them both
Tried a little testrun and the raster was not done all else was.
So much for "done"
I love running around in circles....

Edit (again ):
A few cold beer and a fresh approach is often better than endless code digging.
Reverted back to the original Turnkey firmware, check my last coding attempt for changing the raster power and sure enough for more similar code corresponding to the normal laser moves.
Changed a few lines in Marlin_main.cpp and now ALL modes allow for the 10000 power settings without affecting each other.
Best about this approach is that now all the other Marlin stuff is totally unchanged unlike previous attempts.
Running out of plywood rubbish now so the promised video will done on cardboard instead, just give me a few hours for a break and something to eat

Edited 2 time(s). Last edit at 03/26/2016 02:47AM by Downunder35m.

New posting for this forgetful guy...
In case anyone is looking for the right place to change the power levels without too much hassle, check marlin_main.cpp for the case definitions.
Each case like M649, G1, G7 and so on has all the things needed for minor and major adjustments.
All code handling if done in FLOAT till the actual analogwrite to the laser output pin.
So what is changed here will affect everything along the way without interfering

But whatever you use to do your calculations stick to float values in the coding

Glad you got it sorted!

There is a thing about analogWrite() and that is the default pwm frequency
of 1 kHz. When you crank up the speed on the raster engraving you might notice
that this frequency is too low. For example 90 mm/sec at 10 dots/mm = 900 dots/second.
A pwm signal at 1kHz will not do a good job here.
When I run at max of 500 mm/s engraving at 10 dots/mm, this means 5000 dots/seconds so
a PWM frequency of at least 5 kHz is needed. Now I run with 20 kHz.
I think this will be an issue for you later on.

So far I only get these speeds during raster engravings, not 8bit.
But since you say I will notice the problem sooner or later anyway: where would I change the PWM frequency?
And doesn't the change affect the timers for other things?

Glad you asked

I think one will end up in the analogWrite routine sooner or later [github.com] at line 202.

There are three different types of pins, hardware with real analog output - don't want that. Pwm generated by the builtin PWM-controller - seems like the best choice but it isn't, one can not change clocks because as soon as somewhere else in the program the real analogWrite is used the clocks are programmed back to default 1 kHz - so don't want that either.
The best PWM for the lazing purpose is the one generated by a timer. That means pins 2-5 and 10-13. The upper pin numbers are typically connected to 12V mosfet output. Of pin 2-5 - at least 3 and 5 are found at Servo 4 and Servo3 outputs. That is pretty much what is possible: pin 3 and 5.

I will save you some coding and show the code I use. You will find that it is taken from analogWrite, but cut down;

#ifdef LASER

#define LASER_PWM_MAX_DUTY 255

static void TC_SetCMR_ChannelA(Tc *tc, uint32_t chan, uint32_t v)
{
  tc->TC_CHANNEL[chan].TC_CMR = (tc->TC_CHANNEL[chan].TC_CMR & 0xFFF0FFFF) | v;
}

static void TC_SetCMR_ChannelB(Tc *tc, uint32_t chan, uint32_t v)
{
  tc->TC_CHANNEL[chan].TC_CMR = (tc->TC_CHANNEL[chan].TC_CMR & 0xF0FFFFFF) | v;
}

static uint32_t chA, chNo;
static Tc *chTC;
static uint32_t TC_const;

void laser_init_pwm(uint8_t ulPin, uint16_t ulFreq)
{
  uint32_t attr = g_APinDescription[ulPin].ulPinAttribute;
  if ((attr & PIN_ATTR_TIMER) == PIN_ATTR_TIMER) {
    // We use MCLK/2 as clock.
    const uint32_t TC = VARIANT_MCK / 2 / ulFreq;
    TC_const = TC/TC_MAX_DUTY_CYCLE;

    // Setup Timer for this pin
    ETCChannel channel = g_APinDescription[ulPin].ulTCChannel;
    static const uint32_t channelToChNo[] = { 0, 0, 1, 1, 2, 2, 0, 0, 1, 1, 2, 2, 0, 0, 1, 1, 2, 2 };
    static const uint32_t channelToAB[]   = { 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0 };
    static Tc *channelToTC[] = {
      TC0, TC0, TC0, TC0, TC0, TC0,
      TC1, TC1, TC1, TC1, TC1, TC1,
      TC2, TC2, TC2, TC2, TC2, TC2
    };
    static const uint32_t channelToId[] = { 0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8 };
    chNo = channelToChNo[channel];
    chA  = channelToAB[channel];
    chTC = channelToTC[channel];
    uint32_t interfaceID = channelToId[channel];
    pmc_enable_periph_clk(TC_INTERFACE_ID + interfaceID);
    TC_Configure(chTC, chNo,
                 TC_CMR_TCCLKS_TIMER_CLOCK1 |
                 TC_CMR_WAVE |         // Waveform mode
                 TC_CMR_WAVSEL_UP_RC | // Counter running up and reset when equals to RC
                 TC_CMR_EEVT_XC0 |     // Set external events from XC0 (this setup TIOB as output)
                 TC_CMR_ACPA_CLEAR | TC_CMR_ACPC_CLEAR |
                 TC_CMR_BCPB_CLEAR | TC_CMR_BCPC_CLEAR);
    TC_SetRC(chTC, chNo, TC);
    if (chA)
      TC_SetCMR_ChannelA(chTC, chNo, TC_CMR_ACPA_CLEAR | TC_CMR_ACPC_CLEAR);
    else
      TC_SetCMR_ChannelB(chTC, chNo, TC_CMR_BCPB_CLEAR | TC_CMR_BCPC_CLEAR);

    PIO_Configure(g_APinDescription[ulPin].pPort,
                  g_APinDescription[ulPin].ulPinType,
                  g_APinDescription[ulPin].ulPin,
                  g_APinDescription[ulPin].ulPinConfiguration);
    TC_Start(chTC, chNo);
  }
}

void laser_intensity(uint8_t intensity) {
  uint32_t ulValue = intensity * TC_const;
  if (ulValue == 0) {
    if (chA)
      TC_SetCMR_ChannelA(chTC, chNo, TC_CMR_ACPA_CLEAR | TC_CMR_ACPC_CLEAR);
    else
      TC_SetCMR_ChannelB(chTC, chNo, TC_CMR_BCPB_CLEAR | TC_CMR_BCPC_CLEAR);
  } else {
    if (chA) {
      TC_SetRA(chTC, chNo, ulValue);
      TC_SetCMR_ChannelA(chTC, chNo, TC_CMR_ACPA_CLEAR | TC_CMR_ACPC_SET);
    } else {
      TC_SetRB(chTC, chNo, ulValue);
      TC_SetCMR_ChannelB(chTC, chNo, TC_CMR_BCPB_CLEAR | TC_CMR_BCPC_SET);
    }
  }
}
#endif

The just use it with

laser_init(5, 20000); // 20 kHz on pin 5
laser_intensity(200); // 200 of 255 

OMG
I thought I already started digging into the firmware but now you really want me to waste my time to play with PWM signal too
Not even trying to say I understand all of your code after a quick look but will inspect it much closer next weekend with more time, thanks for that!
Noticed during my engraving for all that there is still a resolution problem with the laser power.
CO2 is not just more powerful than a diode laser it also affects organic materials more directly.
For example instead of burning the wood a bit more like a diode would, the wood just disappears LOL
So that make think I should foucs on using the 8bit engraving in slightly different way than planned.
For images I will stick to high resolution raster engraving, with the right settings it looks really good anyway and gives always even burns.
But the 8bit stuff I will try to use for 3D engravings instead
Have to find the right wood for some tests first and might have to go with a shorter focal lenght to avoid burning too deep into the wood in an unwanted way.

Currently and if I understand the code correctly the Mega uses close to 1kHz for the PWM (927 I think!?), which in my tests with pulsed operation is still enough to get 3000mm/m without laser problems.
Still the problem of stuttering during 8bit is a concern as it limits the possible speed, 1000mm/m is a save speed for me in high resolutions.
During my code digging I noticed that in a lot of places algorithms use FLOAT where, with a few extra lines of code, INT values could be used.
Some even use the float argument multiple times in a single calculation.
Using INT instead should speeds up quite a bit and uses less computing power.
Changing that will be something for very rainy weeks though LOL

Currently I also try to work out what speeds are really needed to read the 8bit data fast enough for processing.
After all this 8bit stuff is the last thing slowing me down in my progress ROFL
Just judging by the amount of data running through Pronterface in comparison to what runs through during normal jobs I already know it won't be an easy task.
But to be fair I also noticed slowdown and even slight stops during vector works in very high detail, some Hershey text in small fonts can be a pain too, not to mention standard text as an outline.
Since the Mega still has a lot of free memory to play with I was thinking of creating a flexible buffer for the currently used ring buffer.
Similar to the buffer enlargment during raster engraving I want to find a way to check the serial transfer against the command processing to increase the buffer.
If I figure out how then I would love to use a fixed percentage of the free memory (to be calculated at program start) with a read-ahead function.
This way the buffer can fill up to the max before the job starts and again if there is chance to read fast enough.
Avoids all the serial chit chat when there is no time for it was my thought here.
Also had a link to some code that would allow a 16PWM resolution on some pins but it requires quite some code changes in Marlin to get it in.
Plus it was not mentioned anywhere how much more processing is needed compared to 8bit.
In any case (and if I find that damn code when I need it) this would solve the laser power problem for good.
Question is: Would a 16 bit resolution really be required or will the change of input range with your PWM mod be enough ? LOL
I knew I should have left the dongle in the PC instead of replacing the controller ROFL
Once you start tinkering there is never an end to it and once you seem to be happy with the outcome a new firmware or much better controller option comes up.
Already see me with a BBP 1S for my printer and another BBP for my laser

The good news is that the code above is for Due, sorry I was so in to my own machine. So ignore,
but perhaps can be useful for someone. But I do have a Mega on my laser diode machine.

For the Mega I use the Timer3 library. Don't know exactly where I got it from, but it is on github on several places.
So the init code is

  Timer3.initialize();
  Timer3.setPeriod(1000000/LASER_PWM);
  Timer3.pwm(pin,0);

and the firing is

  Timer3.setPwmDuty(LASER_FIRING_PIN, intensity/100.0*1023);

where intensity is in the range 0-100. The good news is that Timer3 has 1024 resolution
by default and is very easy to change in the library. There is no extra processing
done, all the counting and changing pin level is built in functionality. Timer 3 work on pin 2,3,5.

The pwm frequency seems to depend on which pin is, 980 Hz is the most for analogWrite().
1000 mm/min at 10 dots/mm will be - lets see - 167 dots per second,
so every dot has 6 full pwm cycles, I guess that can work, When you
engrave at 3000 mm/min at 10 dots/mm there is only 2 full pwm cycles / dot,

Yeah, I too noticed that the laser may just blow away material instead of charring.
Here is small engraving I made in mdf the other day. The shadow under the car
and some brighter areas come out nicely. In the areas full of lines and dots the
material is eaten up and blown away. More than a millimeter is gone haha.

For me 8-bit engraving has good enough resolution. The car is the Inkscape example
"gallardo". Look at the shadows under the car, smooth transition in gray-scale.



When you write 8bit engraving, do you refer to the G7 command? And for high resolution raster
engraving you refer to G1 commands, correct?

I think you should be able to engrave with G7 at about 2500 mm/min stutter-free with the LCD.
Without the LCD a bit above 3000 mm/min is expected. First thing is to test without LCD.
Then test increase BLOCK_BUFFER_SIZE and/or BUFSIZE in Configuration_adv.h.

Edit:
I need add that I think 255 levels are enough if the whole range can be used.
If the laser goes so slow that max intensity is 10%, then only 0-25 is used and that is not good enough.

Edited 2 time(s). Last edit at 03/28/2016 05:38AM by falwty99.

A short video of engraving the car above.

[www.youtube.com]

It is good to see that I am not the only one with the material vanishing instead of getting dark LOL
Tried with some redgum hardwood the other day - disaster!
Although it is claimed not to contain resin like pine the resin content is still far too high.
And due to the massive density difference in the grain it looked more I engraved only between these year rings.
But to my surprise it worked great on a popstick for ice cream, just tiny.
I guess the real trick is to find a semi hard wood with a very fine grain structure, would like to try birch but next to imposssible to find around here.

As for the code generation:
For most of the stuff I just the Inkscape plugin.
Easy to use, does the job and don't really need other programs for my designs.
The 8bit stuff is done by Image2Gcode and only uses the G1 commands.

Currently the PWM is calculated similar to your example already:

    ICR3 = labs(F_CPU / LASER_PWM); // clock cycles per PWM pulse

Right now configured for 8kHz.
For some reason my original Mega gave up last night.
Was setting the buffers to 32 and 8 and when I uploaded the sketch the communication failed.
Thought the code with the higher buffer stuffed processing and uploaded the old sketch to notice I can't.
Mega shows in the Win device manager but no longer in the Arduino IDE.
Flashed new bootloader with the spare Mega as an ICSP even uploaded the blink sketch the same way but no reaction.
Trasfers as working fine but nothing happens to indicate it works on the Mega.
Guess three years of abusive coding and prototyping took a toll on the poor thing.
Now I use a clone with the CH341 chipset.

In raster mode I go to 3000mm/min but 8bit in G1 is down to about 1000 if I don't want constant stuttering.
And for being stupid and forgetting the backup I start from scrtach again with my mods, just good that I know them by now LOL
Still I am not happy with the workings.
It is quite hard to find the right mix of added input range vs loosing proper raster engraving.
My last tests showed a little flaw resulting in just 6 or 8 shades of grey.
You said you have to Turnkey mods in the latest Marlin, mine is based on the 1.0 and I gave up porting the mods over to a new release.
I think it should be possible to get higher speeds in 8bit by modifying the command buffer routinges.
As the speed does not change it should be possible to add another case for this.
Was thinking of the same approach as for the normal raster mode but to encode the power levels instead of the pixel values.
Problem here is that all is done in VS .Net and I already struggle to get Arduino, C, C++ and the plugins sorted ROFL

... I can give you a hint for "raster engraving"

For "high load engraving" of high resolution images with up to 5 Giga-pixels I'm converting a colour image into grey shade and exporting it as RAW file ("endless" Byte-values per pixel shade) with a head containg the X/Y size od the original image.

With this RAW data on a SD card, I only need a synced routine to read the next Byte value (pixel brightnes), set it as analogue value for the laser power, perform a XY-step, burn the pixel (or not, if value =0) , and proceed to the next pixel.

So I can actually do pixel-engraving with roughly 60 kHz without speed-optimizing (standard analogue bit- and SD-card-handling) on the ArduinoDue - calculated into travelling speed this is something like 150mm/s (or 9m/min) with a step resolution of 0.0025mm ...

Edited 1 time(s). Last edit at 03/29/2016 03:32AM by VDX.

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Ok, turned out me first and initial attempt was the right way - from a basic point of view.
After running back and forth through the code I finally realised the problem is with how the raster power is calculated.
The standard of 0-100 works fine, same for as long as I don't go too high here.
The 0 - 10000 works fine for all modes but not for the raster mode.
All calculations are correct, and my assumption that it has to do with the large numbers was confirmed in some very time consuming testruns.
The power correction for the raster mode as done by Turnkey Tyranny makes enough sense to understand.
However:
No matter how hig or low I set the power input levels, e.g. 0-1000 or 0-5000, the normal lasering works just fine - if the S values in the Gcode match the firmware settings of course.
Same for the raster mode up to a certain point.
At first I thought the calculations are turning rubbish as the input of 0-10000 is too much to handle.
Now I know the culprit is somehwere after the power correction.
If either the the set S value or the correction factor for no laser power is higher than 255 all goes bad.
When getting close to the 250 mark the total black areas already get incorrect, lower power outputs.
Best guess is that an overflow happens somewhere but after several hours I am now getting a bit frustrated by all the linked things inside the firmware.
The more you think you understand it the more place you find that you missed before and it does not make it easier LOL
Even though my I still struggle to get the power calculations corrected the removal of some (IMHO not required) float operations in favour for int gave me 4200mm/min for the engraving.
This is already over 20% higher than the vactor speeds I got before.
The EEPROM support was disabled for the testing as well.

Now my hopefully last chase is the case of the 255 problem.
And I am certain it is hiding somewhere inside the firmware ROFL

It was an unsuited type definition in the base64 library - CHAR, where INT would be needed.
Plus the range calculations for the power levels only work on paper or a real calculator, but not correctly on the Arduino.
I replaced them in favour of the MAP command, which is working fine now.