When I rubber band frame the laser indicator crosshairs deactivate. They work fine in the boundary frame mode.Any thoughts?
Ikier Ultra laser
Can you push “Show all” in Console and then make one run of the rectangular frame and then one run of the rubber band frame? Once complete, can you capture the full output and then post here?
Curious to see what the difference could be.
Interesting… I never noticed this before, but my K1 Pro has the same bahaviour (no crosshairs during rubber band framing). I don’t really use them, so I never noticed they turned off.
I’m running the latest firmware. (1.433)
FIrst job is standard framing. Second is rubber band.
Starting stream
G00 G17 G40 G21 G54
G90
G0 X25Y20
M3
G1 X80S2.5F8000
G1 Y75
G1 X25
G1 Y20
M5
G0
G90
Stream completed in 0:04
?
<Idle|MPos:24.999,19.996,0.000|FS:0,0|Ov:100,100,100|A:S>
ok
Starting stream
G00 G17 G40 G21 G54
G90
G0 X80Y75
M4
G1 X25S2.5F8000
G1 Y20
G1 X80
G1 Y75
M5
G0
G90
Stream completed in 0:04
edit:
I did not trim anything from the console output. The “?”, “ok”, & “<idle…” don’t report after rubber band.
This must be something in firmware.
Looks like the difference is use of M3 vs M4. I didn’t realize rubberband used M4 actually. This might be an oversight from when framing switched from M4 to M3 as to reduce diode fluttering when slowing down.
But in any case, looks like the firmware is designed to disable crosshairs with M4 but not M3.
I’ll speculate based on this that if using “Constant Power Mode” that the crosshairs always stay on even for regular burns.
@Rick, can you please check on whether or not rubber band framing using M4 is indeed an oversight? I assume this should also be M3.
I just tested this. Crosshairs turn off regardless of “constant power mode” state.
Out of curiosity, I tried both framing methods with power at 0.25%, 1%, 5%, & 10%. All produce the same crosshair result.
I ran these at 1% power. I also frame at 1% power.
Console output… Normal first, then Constant Power.
Starting stream
G00 G17 G40 G21 G54
G90
M4
M8
G0 X67.5Y92.5
Layer C20
G1 Y167.5S10F2000
G1 X142.5
G1 Y92.5
G1 X67.5
M9
G1 S0
M5
G90
G0 X400 Y740
M2
[MSG:Pgm End]
Stream completed in 0:16
Starting stream
G00 G17 G40 G21 G54
G90
M4
M8
G0 X67.5Y92.5
M3
Layer C20
G1 Y167.5S10F2000
G1 X142.5
G1 Y92.5
G1 X67.5
M9
G1 S0
M5
G90
G0 X400 Y740
M2
[MSG:Pgm End]
Stream completed in 0:16
Those results being what?
And are you saying that the previous behavior of crosshairs off for rubber-band frame while on for rectangular frame is not holding true?
Was this the normal burn job where crosshairs turn off in both cases?
Sorry. I should have more clear.
Crosshairs remain ON at all 4 stated power levels when normal framing. Crosshairs turn OFF at all 4 stated power levels when rubber band framing.
Yes. Normal job started with the “start” button. Only deviation from true normal being the unusually low power so I could safely observe the crosshairs state. I also tried running this normal job at 10% power. Crosshairs turn off regardless of power % and regardless of power mode state.
Excellent set of tests to rule out power level variance.
Really interesting and seems to invalidate my M3 vs M4 hypothesis.
What happens if you run this gcode:
G00 G17 G40 G21 G54
G90
M3
M8
G0 X67.5Y92.5
Layer C20
G1 Y167.5S10F2000
G1 X142.5
G1 Y92.5
G1 X67.5
M9
G1 S0
M5
G90
G0 X400 Y740
M2I copy/pasted those into the console unedited and the job ran with crosshairs ON the whole time.
console output:
G00 G17 G40 G21 G54
G90
M3
M8
G0 X67.5Y92.5
Layer C20
G1 Y167.5S10F2000
G1 X142.5
G1 Y92.5
G1 X67.5
M9
G1 S0
M5
G90
G0 X400 Y740
M2
ok
ok
ok
ok
ok
error:2
Numeric value format is not valid or missing an expected value.
ok
ok
ok
ok
ok
ok
ok
ok
ok
[MSG:Pgm End]
ok
Interesting. I basically changed the Constant Power Mode code to not first issue the M4 before swapping to M3 to mimic the frame code.
I’m wondering if the firmware either turns off the crosshairs for M4 and then stays off even with M3 until the machine comes to a stop. However, M3 in isolation doesn’t turn off the crosshairs.
I’m curious if the crosshair behavior is configurable in firmware.
I don’t know how to edit firmware outside the console. I can upload the firmware file if you’d like.
You’re likely more familiar with Ikier’s customizations than I am at this point.
If you have a reference to the firmware source code that could be useful.
I have the .bin files but have not yet found anybody that has interrogated them in a code editor.
Bin file by itself won’t be of much value unfortunately. If they haven’t been pressed already Ikier/Atomstack need to be pressed to meet their obligations to release source as required by the license GRBL is distributed with.
I can email them and ask. My experience with their support hasn’t been great, though.
What extension should the source code have?
GRBL is mostly C code but they’d likely either link you to an online repository like github that hosts the files or provide you with a compressed set of files in zip or other similar format.
Hello Chris,
There is a newer version 1.449 of the Ikier K1 firmware dated on 7th of July:
https://cdn.shopify.com/s/files/1/0677/4646/4064/files/Firmware_a04b80bc-b37f-43b3-adaf-58020bdbed2f.zip?v=1688960749
Taken from User Manual – iKier (down ant the end)
Interesting. Thanks for that. They’ve changed their links and hosting, apparently.
I last checked in August and 1.433 was latest at that time.
I registered on their website in hopes they would notify me of firmware updates. I guess I was either a bit too late or they don’t notify.
I wonder what changed…
I emailed them back and forth a few times asking for a change log and source code. I finally got the following:
Hello,
We apologize, we’ve reached out to the tech department and they don’t have the relevant source code files to provide us with.
If there is any update, we will notify you as soon as possible. The current latest version is firmware 1.499. It’s the attachment in the previous email.
We apologize for any inconvenience this may cause.
Ikier
Apparently I am at least two versions behind. I have 1.433, while I hear 1.449 and 1.499 are available. I didn’t look close enough at the zip they sent me to see if the 1.499 is a typo. I just noted that it was lacking anything other the two .bin files used for firmware update.
I have another email pending asking if they can/do notify owners of firmware releases (I registered on their website some time ago and have received nothing). I also asked if the firmware can be rolled back. I don’t like the idea of updating with no idea what changed and no way back.
I’ve not seen any GRBL based controllers implement a downgrade lock for firmware but they could be a first.
I find this fascinating. How can they have the binaries without the source? This may mean that the development of the firmware is licensed to an outside party. But in any case, if they refuse to provide source especially to a customer that’s a GPL license violation (under which GRBL is licensed). Ortur went through this recently and started publishing their source on Github after public pressure.