Two issues I've got - any help appreciated!

[paula]

Got my Fabkit up and running now and I’m very happy with the results so far.

I’ve got two issues that pop up from time to time though and I hope you can give me some pointers how to solve these. I’m working with the recommended Smoothieboard firmware and the latest Laserweb running on the Pipo.

Issue 1: I get “ALARM: Kill button pressed - reset or M999 to continue” frequently when trying to start a job or sometimes even during a job. No kill switches have been triggered in either case. I clear the alert and then it usually works normally or there is a second or third alert before it works again normally.

Issue 2: Sometimes when I start a job, the moving speed when NOT firing is greatly reduced (just crawling along, really) and is only at expected speed when firing. I usually abort the job, move back to X0/Y0 (still crawling!), manually jog Y or X axis 10mm and back again (just to confirm there is no mechanical problem) and start the job anew and everything works fine. Manually jogging via Laserweb is always at the expected speed, the issue only occurs sometimes when executing jobs or moving back to X0 or Y0 after such a “failed job”.

Many thanks in advance for any help!

[DeGrazendeSlak]

Very sorry that I can’t help you now, but Bonne or Saskia will tackle the issues. Now and then Issue 2 is also occurring on my FabKit. Not the faintest idea what causes the ‘crawling’. First I thought it had something to do with my Mac/LW4/smoothie connection (I don’t use the Pipo), but apparently that is not the case.
Hopefully you will conquer the issues.

[paula]

Many thanks for your reply! Good to know at least the second issue is not something that only my machine has. And of course that it’s being worked on.

[Martin]

Hi! I can offer you workarounds. Only workarounds, but they work.

For issue 1, remove the yellow abort cable from the smoothieboard. It should be labeled. Don’t worry, there will be plenty safety functions left. At least, that’s what Bonne told me

For issua 2: This happens when you jog the laser with a low speed before a job. For example you lower the bed by 1mm or move the head 1mm and after that he moves like that during the job. To avoid, just jog with high speed before starting. Just move the head right then left using a 100mm step and you’re good.

[paula]

That’s great! Many thanks for sharing the info.

[Martin]

You’re welcome. Be careful when removing the abort cable.

[FabCreator]

@Martin is correct on both counts thanks for posting
Some of the new interlock boards seem to be triggering when they should not, we are looking into the problem once fixed we will send out new boards or whatever the fix happens to be
For now what Martin describes will prevent the machine from aborting accidentally. Don’t worry though as the machine will still turn the laser off if you were to open the door.
This was how the Mk4 handled the interlocks.
The Mk5 introduced the function of abort/machine halt when the door opened, we would like to turn this into a pause apposed to aborting in the future but we have some limitations with the firmware and software.

The slow speed is to do with the default seek rate which is over written every time you send a new one. The Z axis has a slower speed so changes the default speed. Joging the X or Y axis will change the speed back to the higher speed.

G0 is used for movement, G1 is used for laser firing, To prevent this happening what we can try is to add a G0 command at the start Gcode to set the correct feedrate.

Hope that helps

[paula]

Great product and a great community & support.
Thank you all!

[DeGrazendeSlak]

Learning every day. I will try your issue 2 ‘workaround’. I own the previous model Fabkit, but it sounds plausible.

[FabCreator]

Should work for the mk4 too

[DeGrazendeSlak]

Funny coincidence, I once owned a Triumph Spitfire MK4. Happily it had no crawling issues.

[Sebastius]

We have the same issue with the alarm triggering without cause here at Revspace.

I’d really appreciate a way to see what triggered it, but that would probably require me hacking a monitoring arduino on the interlock board

Can you send me the schematics, pcbdesign and logic requirements/flowchart for the interlock board? Maybe we have some insights on how to improve it. (i’ve offered our help a while back, the offer still stands )

Suggestion on machine behaviour:

Pause when alarm is triggered
Show cause
Resume button if cause is solved, override if not solved (sensor defect) or cancel

[Juerd]

The kill button pin is defined as 0.23. I’m wondering if changing that to 0.23^ to enable the smoothieboard’s internal pull-up would help. (It would if the kills are caused by a floating pin from the interlock board, but I don’t know if that actually is the cause of the intermittent kills.)

[FabCreator]

Fabcreator_Logic.zip (364.0 KB)

@Sebastius Here is the file, thanks for the offer I will indeed take you up on it. I have also sent you an email with some more info.

I love the machine behaviour idea. However the only problem is with smoothie ware, The pause function it will wait till the end of the current buffer meaning you could be waiting a few seconds or a few minutes for the job to pause. (A way around this is for smoothie to have smaller line segments with vector pathing, this means the que will empty faster.)

The kill command/button is the only command which will interrupt ahead of the buffer and halt all operations, the downside to this is as we are using steppers position is lost, in addition the current buffer is lost so if the job was to restart not only would you be slightly off in position you would also be missing a segment of your job.

@Juerd The Interlock board was designed to provide a high signal when an alarm was triggered I had planned to use a pin on the smoothie and set it as the Kill switch as open drain, but it did not work.
The only way i managed to get it to work as indented was the current set up you see; using a transistor and using the high from the interlock board to close the kill button circuit. Feel free to try 0.23^ let me know what happens

[Juerd]

I’ve already tried 0.23^ and the lasercutter still works, the interlock still aborts the job, so now it’s a matter of waiting to see whether the problem of random aborts will resurface. Since it went wrong only a handful of times in a few dozen hours of use, it’ll be a while before we can draw any conclusion…

[Juerd]

By now it’s safe to conclude that the 0.23^ setting doesn’t solve the problem.

We’re still getting intermittent M999 crashes, especially during engraving. It’s terrible because wasting material like this is costly.

[FabCreator]

Hi Juerd,

looks like you have been testing 0.23^ for a while then? did it help? I would suggest removing the abort pin as described above so not to waste anymore material.

Regards,
Bonne

[Juerd]

No, it seems the pull-up setting (0.23^) doesn’t change a thing in practice.

Because we have many different people operating the machine, some rather inexperienced, I’m not sure removing the abort wire would be a great idea. If I understand correctly, this would mean that the laser will continue in case the chiller is switched off?

[Juerd]

Bonne, I can’t find the schematics for the interlock board. Could you point me in the right direction?

(Electrical, that is)

Update: Never mind, Sebastius is sending them to me now

[FabCreator]

Hi Juerd,
The zip file is posted further up in this thread. I aslo emailed it to seb In the past so that works too
Removing the abort pin will not effect the interlocks the laser will still turn off if the door opens and or the chiller is off.
All the abort pin does is send a high to the smoothie board which is suppose to abort the current job. So if you open the door the job is canceled.
Kind regards,
Bonne