Thanks! Now I don’t have to totally deconstruct my now working table.
1 Like
Any thoughts from the experts on why I cant get my grbl to home?
It is definitely enabled. The system starts in an alarm state until I order a home. When I give that command, the system responds “ok”, but NOTHING moves. The machine position does not change. The Work Position does not change. My limit switches are at a “low” state, reading about .167V. If i jog the machine to trigger the switches, the voltage jumps to 4.83V
The limit switch pins are set to 32 and 33 in the machine definition (which matches Bart’s 2 channel board schematic)
The machine jogs around happily, but I just cant get it to home! What am I missing?
I had to modify the machine definition file:
//#define USE_CUSTOM_HOMING
#define DEFAULT_HOMING_CYCLE_1 bit(Y_AXIS)
#define DEFAULT_HOMING_CYCLE_2 bit(X_AXIS)
This works, however I have to manually return Y to zero before doing $HX. Then when I do $HX, it makes my Y position equal to the pull back value. In this way, I cant use $H because Y will no longer be engaged in the optical stop when X does its thing. Im still missing something.
Dunno if GRBL supports M119, but that would be where to start with Marlin.
You need to choose how switches will trigger, high or low, and if they’ll be normally open or closed.
If you have them wired NC, try NO. If you are using switches that you cannot configure, change the switch definition.
To test first, press the switches (or block the optical switches) and home the machine. If it moves towards zero, release the switch (or unblock the optical) and see if it stops. If it does, reverse the logic in your firmware.
1 Like
It doesn’t support M119, afaik. In standard grbl, you can add the endstop state to the report. In grbl_esp, it is already there.
Try this, from above.
Adjust the negative values to work with your table, but these should be very close.
Shoot and you need to set the pull off value to 15, so the x axis will clear if homing, from home.
but put this where? Is it a custom macro? Does it go in a .h or .cpp file as a custom homing function? type it manually in the terminal every time I want to home?
I tried to do the above in a macro file on the web ui but the $HY exhibits strange behavior and fails. Yet, typing $HY in the terminal homes perfectly.
Use it as your starting gcode, so enter it into sandify and it will save it (for the files you want homed).
Test it in a file, as long as you have a 15mm pull off set.
damn, that makes too much sense…I am too close to the problem. Treating the zen like my mpcnc that I home by macro against a hard stop before running. The zen is more like a printer that just homes before every job. I will give this a try, thanks!
I have not posted my config or any of this info yet as I am not sure if there is a better way or not.
This homing took me a while to get right, but now it is working every time. I did have some others that would work…occasionally. Real brain twister.
You can also just put it in a file called “home.gcode” and only home it when you need to.
I still haven’t installed my endstops. I just manually set the zero with G92 and I just don’t turn it off.
This worked BEAUTIFULLY! “KISS” method definitely applied to me here.
I just ran my first test pattern (albeit no sand), and it went nice and smooth. I had to repair a corner chip on my glass that occurred from grinding it to fit the frame. When the Epoxy is cured I can add sand and close her up. Then I just need hook up the lights.
The only tiny problem I am still having is that the WebUI wont allow me to graphically read or upload to my sd card. The card is there, and readable, but only though the terminal. To print, I have to to $SD/Run=/sandify.gcode. I almost dont mind this, but its the uploading that is really bothersome. The point of the ESP board was to do NO SD card fiddling.
I tried a 1gb card and an 8gb. I read on the wiki that it must be 4gb and under, but both work in the terminal, and NEITHER work in the file window.
Thanks for all the help!
Maybe compare with my version…be careful. I did change a few extra things in a couple files if I remember right.
My file upload works well, but that might be on the windows side.
I don’t know if I’m missing something in this thread, but when I setup grbl-esp32, it took me a while to figure out the homing cycle order isn’t set in the firmware any more. It’s set from the console as options. I forget how, since it’s been a couple months.
EDIT: Found it. Took me a minute, I thought I was going crazy.
Scroll down to the “Grbl Settings” section.
The wonderful people on the he grbl_esp Discord solved my SD card problem.
In case this helps anyone else: if you use the arduino IDE to compile grbl_esp, install the Version 1.0.4 esp32 board in the board manager, NOT 1.0.6.
My fw was crashing every time the webui tried to read the sd card, due to some stack overflow issue (way over my head). I’m all good now!
2 Likes
Ok, so wLED is just as fantastically awesome as advertised. Thank you Jeff for steering me in the right direction with that one!
I am a bit confused by the power output of my strip. At full brightness, it is probably plenty bright for my application, but its not nearly as bright as I expected. I am not sure why I care so much, since I wouldnt want my coffee table shining annoyingly in my face, AND the low power supports me pulling power from the controller board to simplify wiring.
However, the fact that it just doesnt make sense if bugging me! The strip is advertised for a max of 6A @12V for 300 leds in 100 pixels of 3 die each. I estimate each pixel eats 60ma. I cut my strip to 134 leds, or 44 pixels. At full white, this would be 60ma X 44 = 2.64A. However when I breadboard this out with an ammeter, I was getting 860ma. I noticed that the voltage was dropping to about 10.5 at the strip, so I added a wire pair to the END of the strip for voltage injection. This made a marginal difference and got me to 1.07A.
This is still half as bright as it should be. I am using a converted PC server PSU as a bench top supply, so it should have NO problem putting out 2.64A. Could I really be losing that much voltage in the breadboard and associated wiring? The connecting wires aren’t THAT long. and the wires that were pre-soldered on the strip were pretty small gauge themselves.
Any thoughts from the LED strip experts? I am a mechE, but usually decent enough with the electrons to get by.
1 Like
Each led is about 20mA, so one rgb pixel is about 60mA. But it also depends on the specific model. The ones I’ve used are the 5V basic ws2812b, which have 60mA per pixal and draw that much as long as they are close to 5V and the ws2815, which is ,12V with two data wires. The 2815 have a strange circuit arrangement to use 20mA per pixel on full red, or full white. In my tests, they work perfectly normal until the voltage drops below 5V.
Also, wled will limit the current (not with a measurement, just a prediction). So you may want to check that in the led settings.
More info on some variants:
I am using the ws2811 strip, 12V input. Each addressable pixel is actually 3 leds in series.
And I removed the current limit, which I plan to use as an extra layer of protection once installed, but for testing I turned it off.
1 Like
Oh. That makes more sense.