cprezzi / grbl-LPC

Multiple compiled versions for different boards & machines (under releases)
Other
56 stars 39 forks source link

Sbase doesnt update GRBL LPC firmware #33

Closed deadjai closed 4 years ago

deadjai commented 4 years ago

Hello, i have a MKS Sbase v1.3 board and i am trying to flash the GRBL LPC firmware to the board. I have downloaded the precompiled frimware bin for the sbase board and tried to add the renamed firmware.bin to the sdcard for the board. The firmware.bin file never changes to firmware.cur after i boot up the board. when i use laserweb it connects properly but it says the firmware is smoothiexxx. i have formatted the sdcard using sdformat app. im not sure why the board wont accept the firmware.bin.

thanks

deadjai commented 4 years ago

I just want to clarify for everyone else out there that are having the same issue as there alot of threads dealing with this. For windows 10 users do NOT add a .bin to the file name when putting on the firmware file. if you add firmware.bin its actually adding firmware.bin.bin. Windows 10 automatically knows its a .bin file so just name the file as firmware

cprezzi commented 4 years ago

Good point! Windows does not show known file extensions (like .bin) by default. You can change that behavior in the settings of the file explorer. See https://www.howtohaven.com/system/show-file-extensions-in-windows-explorer.shtml for more details.

deadjai commented 4 years ago

Hey Claudio, thanks for the advise. We sometimes forget about the simplest things when dealing with the complexities of the boards.

I had another question, I’ve loaded the firmware to the sbase board. Everything works awesome! I’m having just one issue. My end stops don’t seem to registering to the board. I have a NC set up with end stops. I know they work because I just came over from mach3 and they were working fine. I have connected all my wires coming off the limit switches NC terminal to p1.24 and p1.26 (x - and y-) and the com to the ground of 1.24.(Only using x and y) They are run like the picture below. I have also tried reversing the set up where com is p1.24 and NC is ground. They don’t seem to be working at all. My $5=1 for NC. Am I missing something? Such as inverting the pins or pull up resistors? Maybe rc filters?

Thanks! John Iskander

cprezzi commented 4 years ago

You can find the configured pins in cpu_map.h @ line 518... https://github.com/cprezzi/grbl-LPC/blob/84070bf79116ffeec5168a86fdce5795f78a89da/grbl/cpu_map.h#L518

In a NC setup you need to invert the limit pins by sending $5=1. See https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration for details.

Be aware that the limit mask uses all 4 axes. If you don't have a 4th axis, you need to add a jumper to P1.29. Same to P1.28, if you have no Z limit switch.

deadjai commented 4 years ago

Thanks Claudio, I followed what you said. Jumped pin 1.28 and p1.29 (signal to ground) have my x axis NC to 1.24 and y axis NC to 1.26 and com to the ground of p1.24. $5 =1. I tested the limit switches to see if the board can read them. I used a terminal server to send $10=19 then entered ?.

I got a response from the board, when nothing is being pressed the last character of the message given is Pn:P> when I hold down the x limit switch it says pn:px> when I hold down y limit switch it says pn:py>. This seems like the board can read them but when I press them while the machine is operating it does not stop the machine. I fee like I’m missing something very simple.

Any insight would be much appreciated! Thank you for all your help!

John Iskander

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is prohibited.

On Nov 21, 2019, at 10:37 AM, Claudio Prezzi notifications@github.com wrote:

 You can find the configured pins in cpu_map.h @ line 518... https://github.com/cprezzi/grbl-LPC/blob/84070bf79116ffeec5168a86fdce5795f78a89da/grbl/cpu_map.h#L518

In a NC setup you need to invert the limit pins by sending $5=1. See https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration for details.

Be aware that the limit mask uses all 4 axes. If you don't have a 4th axis, you need to add a jumper to P1.29. Same to P1.28, if you have no Z limit switch.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

cprezzi commented 4 years ago

Usually the limit switches are only configured for homing, and not as axes endstops. After homing, the max travel configuration of each axis should limit the travel distance (soft limits). I would not recommend to configure hard limits.

deadjai commented 4 years ago

Oh that makes a lot more sense now! I was comparing from the Mach 3 setup. Thanks!

So I did notice one thing, when I jumped p1.29 and ran a job the machine just went haywire and ran down the x axis not following any coordinates. When I disconnected the jumper on p1.29 it ran perfectly. Any idea why p1.29 would do that? Is it absolutely needed for homing to work?

John Iskander

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is prohibited.

On Nov 22, 2019, at 5:17 AM, Claudio Prezzi notifications@github.com wrote:  Usually the limit switches are only configured for homing, and not as axes endstops. After homing, the max travel configuration of each axis should limit the travel distance (soft limits). I would not recommend to configure hard limits.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

cprezzi commented 4 years ago

That sounds weird. Did you configure all homing and soft limit settings according to the wiki?

Homing should work like this: After sending $H the machine first moves Z and then X & Y to the configured homing direction until it reaches the limit switches. Then each axis should back up the configured distance (like 5mm) and slowly move to the limit switch again. Then each axis coordinates are set so the bottom left corner is 0/0.