Laser engraver m67

PCW, I understand what you write, but can't find the pin you refer to. Can you please be explicit?

joint.N.joint-vel-cmd

Hakan,
just tested your hal file and there is some problem with it. Gcode run but laser doesn't respond, just don't turn on.
Sorry for late response, have no time in the last days.

Wonder what that can be? I'll see if I can find anything.
It looked ok here when I tested, but I don't have a laser so only looked at the numbers.
Doesn't help you of course. I'll come back.

Edit: One thought here. Did you try to actually engrave? Because as it is done now
there need to be a travel speed for the laser to light up.
Basically Intensity = orig.intensity*speed. If you were standing still and just testing the laser
it will not light up due to speed=0. This can be changed later on I guess, if the result seems ok.

I engraved sample file for this test with my config to see the difference and just changed config with your settings and run the same file and laser won't turn on, but gcode running.

Kaspret wrote:

I engraved sample file for this test with my config to see the difference and just changed config with your settings and run the same file and laser won't turn on, but gcode running.

I tried it here and it works well here. It works just as expected. A way to actually notice the change it lower acceleration on the X-axis to something stupidy low like 10 mm/s2. At the axis turning points, the intensity will go down from 0.9 to 0 gradually over like 1-2 seconds, so there is plenty of time to see the change.

I think you have to try to debug this in your environment. I can not replicate the error.
Are you familiar with the "halshow" utility. You can watch pins, signals, etc in real-time there.
Bring up the "intensity" and "analogout" signals in watch mode. Run the engraving.
You should see those two variables having the same values except for some decimals maybe.
And at the turning point the analogout will go down to zero, but it can be hard to notice with fast acceleration.

And analogout should go to the pwmgen as the analog signal did from the beginning.
In the attached g-code file, you should expect a lot of "0.9" in both analogout and intensity signals.

Just checked under halshow and analogout stay at zero
added video below:

Aaah, I see!

Change "x-pos-fb" to "xpos-fb" and
"y-pos-fb" to "ypos-fb" in custom-hal.

I just assumed.... something wrong.

And now it's working, after a while will update with pictures.
Many thanks

update,
picture :
drive.google.com/open?id=1g_YjnWVEX6k_2mgPnmzUAORvnapU65-8
engraved:
drive.google.com/open?id=1GoN4fhQYntw_mE1fSHOIRYVpS8ffsv4j
drive.google.com/open?id=1N29wdKANKLzQJ1DsQibkuIgOAfHwH4ch

Probably not best file to cut, but can see the difference

Both figures look great! Really good blackness, contrast and sharpness.

The question is if the laser follows the contour of the picture, or does it follow the rectangular outline?

Edit: I ask because I can barely see any difference. There are no clear signs of overexposure, like in the very first engraving in this thread. Maybe the contour lines on the right engraving are a tad thinner, but it may also be the camera.
Does the laser change direction at the edge of the figure or at a larger rectangle?
The "fix" will only make a difference when engraving at lower-than-nominal feed, like when switching direction.

I have pondered over the nominal feed speed, it is hard-coded in the hal file. There ought to be a more general way to give that value. There are two things I have found problematic there.

First to get the Fxxx-value and I dont mean u*k but the speed numbers. From motion

motion.requested−vel OUT FLOAT

The current requested velocity in user units per second. This value is the F-word setting from the G-code file, possibly reduced to accomodate machine velocity and acceleration limits. The value on this pin does not reflect the feed override or any other adjustments.

This would have been OK to use had it not been for the "possibly reduced..." sentence. It has to be the actual F-word without changes.

Second, I can't seem to find a "division" module in hal. Is that deliberate to avoid division by zero, or am I not looking hard enough?

At this point I kind of think that a possible way is to enter the reference speed asand in the hal file replacewith