search

terjeio / grblHAL

This repo has moved to a new home https://github.com/grblHAL
231 stars 90 forks source link

Breakout board development #114

Closed phil-barrett closed 3 years ago

phil-barrett commented 3 years ago

I am not sure the best way to do this. If this is wrong, please point me in the right direction. I know it isn't a traditional github "issue".

I feel that having lots of good quality BreakOut Boards available to users is key to the success of grblHAL. As many know, I have one that is doing ok (a fair number of sales, good amount of interest). I won't get rich doing that but it pays for itself, helps fund future development and I am helping spread the word of St Terje. (lol, sorry) More importantly, I believe we need more and different breakout boards that people can buy and use without having to do circuit layout or maybe even software builds. Yes, I am inviting competition but that is OK. The more, the merrier. Our unifying goal should be to make grblHAL the top 32-bit Grbl.

As some of you might know, I have purchased grbl.org and am slowly adding features to it. I would be happy to promote any grblHAL BOBs there. And would love to have collaborators to help make it a place to promote grblHAL. You can message me through the Tindie site for my breakout board if you don't want to comment here.

I think the STM Nucleo-64 might be a good basis for a number of simple BOBs by using the Arduino Uno Pinouts. Since there are CNC shields out there, a user could put a controller together pretty easily. I don't know if there is an Arduino Uno mapping for that already though I confess I don't quite understand the STM32F map files. I see the F411 morpho map file. A little tidying on that to point a low skill user in the right direction would be nice. I can host a step by step instruction guide if someone wants to write one up. Or, it could go in the wiki. Either way works for me. A video tutorial would be fantastic if anyone wants to try.

A better approach is to use the morpho pins. I believe Terje has a map file for the F411. I believe there are others for the STM32F4xx family but am not 100%. I'd like to see one for the F427/429 for ethernet. The biggest barrier is the lack of a morpho BOB that people can buy right now. I know of one well thought out design in progress (not sure if the designer wants me to name him here). The ability to just drop a prebuilt binary on a drive to load the firmware is a very desirable feature. (I'm looking at how that might be possible on the T41 board.)

Longer term, I am designing an F411 board that has the processor on the BOB. Manufacturing costs are looking reasonable - $40 or so end user cost. (But don't hold me to that!) I am wading through the F411 pin limitations right now. Terje is an invaluable resource for that!

So, if you have an idea for a BOB, why don't you jump in? I am happy to help you think it through or answer any questions you have.

Phil

HuubBuis commented 3 years ago

I feel that having lots of good quality BreakOut Boards available to users is key to the success of grblHAL.

I agree but just so much that it covers the usage.

phil-barrett commented 3 years ago

Yes. I think it might worthwhile to understand common usage scenarios. To help better target the users' needs. For routers, I see a couple:

I am not sure how the lathe market segments. I am ignorant of the 6 Axis need - can you enlighten me?

HuubBuis commented 3 years ago

I am not sure how the lathe market segments. I am ignorant of the 6 Axis need - can you enlighten me?

Developing lots of board is expensive. A few universal boards (one size fits all) will be cheaper to produce. My rotary table uses 1 stepper, I have plans for a second one for locking the table. My lathes currently uses 3 steppers (X,Z, Spindle), I have plans for 2 more for adding an automatic tool changer. The RAMPS board has 5 stepper sockets, adding 1 spare makes 6. I think the majority of the lathe users will use 2 steppers.

Could use step stick drivers.

On all my boards I now use step stick drivers and headers for external drivers. Easy testing on the bench and flexible.

To become a preferred choice you need something others lack. That is surely more than extra drivers! Make good mature products (harware, software, support), target the starters and provide a grow path to bind them in future.

terjeio commented 3 years ago

My st-morpo board is IMO pretty close to universal if four stepper drivers is enough.

I have 10 boards in the post so should be here soon. Not cheap as it is 4 layers and gold immersed (I do not like HASL when soldering myself). Expensive BOM too with 16 optos, GPIO up to 30V for many pins, selectable voltage for I2C interface with 5V tolerant interrupt input, FRAM, SD-card/SPI/GPIO header, Trinamic driver support, SPI connected, secondary UART for MPG/DRO or ModBus connectivity, pins that can be used as encoder inputs...

So way too feature rich and expensive for the average grbl user?

Extending MCU support for existing RAMPS or UNO footprint boards could be one option going forward, this by making compatible base boards with a higher end processors? But then grblHAL already has a driver for RAMPS on Re-ARM and the Nucleo-64 boards (and others) has UNO footprint connectors available. And there is one person, @moffy, working on a grblHAL driver for a NXP iMXRT1020 dev board that could bring ethernet and other options to UNO style boards (at a price).

For RAMPS and UNO style boards a concise write up of what is needed (or not) for 3.3V compatibilty would be helpful?

Moffy commented 3 years ago

Nice feature set and nice board. I've played with the STM32's and their SDK's a bit but preferred NXP's. Just a preference though.

phil-barrett commented 3 years ago

Yes, RAMPs is a potential (needs the Mega footprint, ugh) and worth targeting. I worry about EMI, though. All those pin headers are little antennas receiving broadcasts from Radio Free Reboot. A reputation of reliability is important for grblHAL.

Still, it is cheap. The re-Arm base board has some filters for the inputs and it's a reasonable price (list is $45 but sells for $30). Cheaper from AliExpress but then shipping (cost and time) is an issue.

I've never played with one so don't know what it would take to get it up and running. I would be happy to host a tutorial for this. What do we need? Prebuilt binaries? Instructions for the RAMPs board configuration?

phil-barrett commented 3 years ago

I am not sure how the lathe market segments. I am ignorant of the 6 Axis need - can you enlighten me?

Developing lots of board is expensive. A few universal boards (one size fits all) will be cheaper to produce. Yes. That's why I have a 5 Axis board. The cost difference for extra Axes is minimal (mostly connectors).

My rotary table uses 1 stepper, I have plans for a second one for locking the table. My lathes currently uses 3 steppers (X,Z, Spindle), I have plans for 2 more for adding an automatic tool changer. The RAMPS board has 5 stepper sockets, adding 1 spare makes 6. I think the majority of the lathe users will use 2 steppers.

Could use step stick drivers.

On all my boards I now use step stick drivers and headers for external drivers. Easy testing on the bench and flexible.

What kind of stepper motors are you using? The opposing forces for lathes are not that high?

phil-barrett commented 3 years ago

My st-morpo board is IMO pretty close to universal if four stepper drivers is enough.

I have 10 boards in the post so should be here soon. Not cheap as it is 4 layers and gold immersed (I do not like HASL when soldering myself). Expensive BOM too with 16 optos, GPIO up to 30V for many pins, selectable voltage for I2C interface with 5V tolerant interrupt input, FRAM, SD-card/SPI/GPIO header, Trinamic driver support, SPI connected, secondary UART for MPG/DRO or ModBus connectivity, pins that can be used as encoder inputs...

So way too feature rich and expensive for the average grbl user?

I don't think the feature set is too rich but a good round of cost reduction could help. For example, You have 4 4-channel optos on that board. Going to single channel optos allows you to chase volume price reductions. 50 boards would take 200 of the 4 channel optos but 800 of the single channel ones with a larger volume discount. A 4 layer board is not significantly more expensive than 2 layer but gold definitely is and HASL is fine for a production line (all my PCBs are HASL).

Anyway, the real cost drivers are the connectors. Not only do even mediocre connectors cost more than silicon (in general) but they also add manufacturing cost. Pick and place machines have made SMD boards super cheap to assemble. A lot of TH assembly is still by hand, especially at smaller scale production. This one of the reasons I started with the Unkit approach. Getting 20 or 30 SMD only boards manufactured is not only cheap, it is fairly easy to do these days.

Extending MCU support for existing RAMPS or UNO footprint boards could be one option going forward, this by making compatible base boards with a higher end processors? But then grblHAL already has a driver for RAMPS on Re-ARM and the Nucleo-64 boards (and others) has UNO footprint connectors available. And there is one person, @Moffy, working on a grblHAL driver for a NXP iMXRT1020 dev board that could bring ethernet and other options to UNO style boards (at a price).

For RAMPS and UNO style boards a concise write up of what is needed (or not) for 3.3V compatibilty would be helpful? Certainly! I commented on this separately.

phil-barrett commented 3 years ago

Nice feature set and nice board. I've played with the STM32's and their SDK's a bit but preferred NXP's. Just a preference though.

I am a fan of NXP too. That's why I went with a Teensy to start with. I'm not to the point where I can do BGA layout or I would try for an iMXRT1062 layout.

The 1020 is interesting (M7!) though the EVK is kind of expensive. Are there any cheaper boards out there?

terjeio commented 3 years ago

I've never played with one so don't know what it would take to get it up and running. I would be happy to host a tutorial for this. What do we need? Prebuilt binaries? Instructions for the RAMPs board configuration?

I have a modified Re-ARM board (with JTAG brougth out to a pin-header for programming) and a RAMPS board here. The driver seems to work ok except limit inputs beeing routed to pins without interrupt capability means that hard limits cannot be enabled. I can add polling for that. Note that I have not tested with the RAMPS board attached as I am not sure about 3.3V compatibility.

Re-ARM can program itself from a SD-card so prebuild binaries should be easy to load.

And yes, the RAMPS board does not impress me - it is basically just a bunch of connectors.

BTW the same driver can be used with Smoothieboard, so another (untested, no ethernet yet) option for grblHAL.

HuubBuis commented 3 years ago

What kind of stepper motors are you using? The opposing forces for lathes are not that high?

Nema17, 0.5 Nm for the rotary table Nema23, 1.26 Nm for the lathes X and Z Nema24, 4 Nm for the lathes spindle, is attached using a lever for knurling, broaching, grinding, some times for threading

Some people use 15 Nm steppers on larger lathes. When external drives are used, the motor size isn't an issue.

I have an S109 stepstick driver that could/should handle 4A. Didn't test it at this load (will do this some time) but it could make wiring pretty easy.

phil-barrett commented 3 years ago

I have an S107 stepstick driver that could/should handle 4A. Didn't test it at this load (will do this some time) but it could make wiring pretty easy.

do you have a link for that? all I get are helicopter parts.

HuubBuis commented 3 years ago

Sorry i mentioned the wrong part

https://wiki.fysetc.com/S109_V1.1/

phil-barrett commented 3 years ago

hey-zeus! I am kind of skeptical that tiny little driver and heat sink can handle the heat of 4 Amps. But if it can do 2 Amps it is well ahead of the game. Would love to hear the results of your testing. I might have to rethink my opinion of the step stick format.

HuubBuis commented 3 years ago

The S109 runs on a RAMPS 1.6 shield and on a breadboard. I can't get it running on a (single) step stick driver board I have made for testing. Could be the 3.3 logic voltage I am using. I will do some measurements and swap the processor.

I am kind of skeptical that tiny little driver and heat sink can handle the heat of 4 Amps

A larger heat sink like on the RAMPS 1.6 shield could increase the cooling capacity, at least for a short time.

Will be continued...

terjeio commented 3 years ago

I am kind of skeptical that tiny little driver and heat sink can handle the heat of 4 Amps.

Will it "cook" the pin header pins/sockets at that kind of current? A check on the first a search found for me says "Current rating: 3 A" for a gold-flashed pin header.

phil-barrett commented 3 years ago

I am kind of skeptical that tiny little driver and heat sink can handle the heat of 4 Amps.

Will it "cook" the pin header pins/sockets at that kind of current? A check on the first a search found for me says "Current rating: 3 A" for a gold-flashed pin header.

Especially with the cheapo plastic on some of those pin headers. A second too long with the soldering iron turns them into goo.

But still, the idea that a step stick can handle more than 1A is intriguing.

terjeio commented 3 years ago

Could be the 3.3 logic voltage I am using.

It should work with 3.3V signalling, but not with 3.3V Vcc according to the datasheet:

"VCC voltage range 4.75V(min) to 5.0V(typ.) to 5.25V(max)"

The 4A motor current is an Absolute maximum rating with the following note:

"Usually, the maximum current value at the time should use 70% or less of the absolute maximum ratings for a standard on thermal rating."

phil-barrett commented 3 years ago

leave it to the marketeers (we used to call them marketing weasels) to create utterly false expectations.

HuubBuis commented 3 years ago

According to this picture from the board manufacturer Fysetc Wiki, it should work using 3V logic supply voltage. That is different from the Toshiba data sheet. I guess the datasheet is right. S109-wiring-diagram There is also an "electrical angle reset pin". If I remember correct, it had to be set to a high level to get it working on the breadboard. But that could be depending on the microstep settings. On the RAMPS 1.6 shield it floats.

I have connected the logic supply voltage to 5V and it works, thanks. I checked the input pins, they have a pull down resistor so it is still safe to connect a 3V processor.

A check on the first a search found for me says "Current rating: 3 A" for a gold-flashed pin header.

I use JST-XH connectors that have a comparable pin size. They are also rated 3A.

Moffy commented 3 years ago

Nice feature set and nice board. I've played with the STM32's and their SDK's a bit but preferred NXP's. Just a preference though.

I am a fan of NXP too. That's why I went with a Teensy to start with. I'm not to the point where I can do BGA layout or I would try for an iMXRT1062 layout.

The 1020 is interesting (M7!) though the EVK is kind of expensive. Are there any cheaper boards out there?

Yes but only a couple. It's surprising that the chip cost of the RT1020/1 vs the RT1062 isn't that great. The chips are relatively cheap but it's the features you add that will add up. The most interesting possibility is the Embedded Artist's: https://www.embeddedartists.com/products/imx-rt1062-oem/ for value as well as the Teensy4.1, but the Teensy because of its form factor compromises the chip feature set. Compared to the STM32 nucleo boards the imxrt evaluations are overpriced. What would be nice would be a processor board with RAM, flash, USB and JTAG with all the I/O available via connectors, similar to the Embedded Artists, but maybe with just headers for the connectors which could plug into a baseboard, depending on need. Similar to what Waveshare do for their LPC4337 board but smaller.

phil-barrett commented 3 years ago

The EA board looks pretty nice but that connector... I wish there was a compute module about the size of the Teensy 4.0 with dual rows of pins on each side. I've pushed Paul on that point and a lot of people are asking for the graphics pins. As it is, even the T4.1 doesn't have enough pins. His response is MicroMod and that doesn't get more pins out though it does reduce the processor card footprint.

The NXP pricing scheme is old-school semiconductor company thinking. Atmel reaped huge benefits from the Arduino and that pushed a lot of companies to rethink the development board strategy. NXP obviously didn't get the message.

Moffy commented 3 years ago

It wouldn't be that hard (He says in ignorance) to make a board like I described. Some pins like the graphics would need a special connector but by and large most could go out via header style pins. Someone like PCBWAY could be contracted to assemble for the RT1062/RT1064 bga package. For the LQFP packages self assembly would be possible.

Moffy commented 3 years ago

Also found this: https://au.mouser.com/Search/Refine?Keyword=VisionSOM-RT, nice development system for the RT1052 and a modular board. I understand the edge connector because of speed considerations.

infamous-panda commented 3 years ago

Yes. I think it might worthwhile to understand common usage scenarios. To help better target the users' needs. For routers, I see a couple:

  • 3 Axis moving bed machines: lots of super cheap chinese "3018" routers like this. totally crap electronics. Nema 17 motors. Other small machines builders put together. Could use step stick drivers. large potential market. Maybe the Arduino Shield fits here.
  • 3 Axis moving gantry machines. These are the WorkBees and Lead machines. PrintNC is probably in this segment. Sweet spot for builders. Uses mostly Nema 23s, ganged motors for Y. Uses external drivers. Things like my T41 BoB target this.
  • 4 Axis machines. These are the above 3 Axis machines with a 4th Axis. Smaller market though higher value machines and more serious builders.
  • I think there is a laser controller market segment that probably needs just 3 Axes (one for bed height control) but I'm no expert.

I am not sure how the lathe market segments. I am ignorant of the 6 Axis need - can you enlighten me?

Hey Lasers need 4th axis love too! This is awesome I have been researching faster alternatives to our GRBL-LPC setup. Hoping to give this a try.

phil-barrett commented 3 years ago

OK, not a problem. Lasers need 3 and 4 axes.

terjeio commented 3 years ago

Hey Lasers need 4th axis love too!

CO2 lasers will get more love when driver updates for the laser plugin are ready. WIP. Note that only some of the drivers will be updated - iMXRT1062 and STM32F4xx will be first.

infamous-panda commented 3 years ago

Hey Lasers need 4th axis love too!

CO2 lasers will get more love when driver updates for the laser plugin are ready. WIP. Note that only some of the drivers will be updated - iMXRT1062 and STM32F4xx will be first.

I just purchased a Teensy 4.1 (the GRBLHAL breakout is out of stock) to do some testing on the throughput. I had the assumption that I would at least be able to test out the firmware and sort out the features before changing out the guts of our laser lathe setup.

We have what I think is a cpu bottleneck using LPC1768. The setup is a large dedicated rotary axis laser. We cut and engrave plastic rods from up to 8 (200mm) inches in diameter and 8 ft (2500mm) long. Our CAM produces a helical motion like a lathe so we only accelerate and decelerate at the end of the job. Because of this we can mechanically achieve very high surface speeds. But our current cpu cannot keep up with all the lines of G-Code. I am hoping that the iMXRT1062 can do a better job.

I am currently testing out a Duet2 but reprap requires some changes to our code and seems not fully baked for lasers yet.

I am looking at Tom's Robotics F46 GRBL STM32F407 board which claims a step rate of 550khz, but from what I understand all 6 axis are linear and none are rotary. They have not responded to any of my questions.

I also found that the LX4 from VMS Laser accessories which features 16 bit pwm and a proprietary closed version of GRBL which is supposedly faster than LPC

Quick question

I am not clear on what the laser plugin does. My understanding is that dpi and ppi was dependant on the raster Gcode produced and was not relevant to vector cuts. Is this plugin necessary for laser operation in GRBLHAL?

I assume that that the breakout board is just for making things easier but I can connect external stepper drivers and relays to the Teensy directly.

Below is a video of a small test piece we are processing if your interested

https://photos.app.goo.gl/s1rfD8VVWXEaDmY36

terjeio commented 3 years ago

But our current cpu cannot keep up with all the lines of G-Code. I am hoping that the iMXRT1062 can do a better job.

If your gcode is a lot of short movements then increasing the planner buffer size could help a lot to get the feed rate up. How the gcode is sent will also play a role. Most grblHAL drivers has a 1024 byte serial input buffer and with "agressive buffering" it is easier to keep the controller busy at all times.

I am looking at Tom's Robotics F46 GRBL STM32F407 board which claims a step rate of 550khz, but from what I understand all 6 axis are linear and none are rotary.

By rotary you mean that rotary axis distance is sent in degrees of motion? If so grblHAL has support for linear axes only. This could be changed? From linuxcnc docs:

"By wrapped linear axis, we mean one on which the angular position increases without limit (goes towards plus infinity) as the axis turns counterclockwise and deceases without limit (goes towards minus infinity) as the axis turns clockwise."

BTW is the LPC1768 running grbl? If so which port?

I am not clear on what the laser plugin does. My understanding is that dpi and ppi was dependant on the raster Gcode produced and was not relevant to vector cuts.

IMO it is most relevant to vector cuts - PPI delivers a relatively constant power to the cut independent of feed rate, e.g during acceleration/deceleration in corners. For constant speed engraving/cutting it is not that useful.

Is this plugin necessary for laser operation in GRBLHAL?

No.

infamous-panda commented 3 years ago

Admittedly I have a very little experience in any of this so forgive me if my terminology or statements do not make sense.

BTW is the LPC1768 running grbl? If so which port?

We are running GRBL-LPC on a MKS Sbase, specifically cprezzi's fork which includes support for a rotary 4th axis https://github.com/cprezzi/grbl-LPC

If your gcode is a lot of short movements then increasing the planner buffer size could help a lot to get the feed rate up.

This is one avenue I was going to look at by was nervous in changing anything in the code my limited understanding of how any of this works.

By rotary you mean that rotary axis distance is sent in degrees of motion?

I think so. when I type in A3600, I expect that axis to rotate 10 times. Because we spin our work continuously we have code where the A axis values end up in the hundreds of thousands.

IMO it is most relevant to vector cuts - PPI delivers a relatively constant power to the cut independent of feed rate, e.g during acceleration/deceleration in corners. For constant speed engraving/cutting it is not that useful.

My understanding is that GRBL's laser mode already does this in some form. Below is from the wiki

Laser Mode Overview The main difference between default Grbl operation and the laser mode is how the spindle/laser output is controlled with motions involved. Every time a spindle state M3 M4 M5 or spindle speed Sxxx is altered, Grbl would come to a stop, allow the spindle to change, and then continue. This is the normal operating procedure for a milling machine spindle. It needs time to change speeds.

However, if a laser starts and stops like this for every spindle change, this leads to scorching and uneven cutting/engraving! Grbl's new laser mode prevents unnecessary stops whenever possible and adds a new dynamic laser power mode that automagically scales power based on current speed related to programmed rate. So, you can get super clean and crisp results, even on a low-acceleration machine!

Enabling or disabling Grbl's laser mode is easy. Just alter the $32 Grbl setting.

To Enable: Send Grbl a $32=1 command. To Disable: Send Grbl a $32=0 command.

terjeio commented 3 years ago

We are running GRBL-LPC on a MKS Sbase, specifically cprezzi's fork which includes support for a rotary 4th axis

Ok, then I believe "rotary axis" just a convention. "Rotary" is achieved by setting steps/mm appropriately. See below.

If your gcode is a lot of short movements then increasing the planner buffer size could help a lot to get the feed rate up.

This is one avenue I was going to look at by was nervous in changing anything in the code my limited understanding of how any of this works.

I did a short test a while back with 300 entries in the buffer, got a lot higher feedrate when many short moves was commanded. Worth a try. Note that increasing the buffer size increases processor load. The LPC1768 does not have a FPU so will be a lot more affected by this than a processor having a FPU. The Teensy 4.1 is in a totally different league at 600MHz and with a FPU...

I think so. when I type in A3600, I expect that axis to rotate 10 times. Because we spin our work continuously we have code where the A axis values end up in the hundreds of thousands.

IMO this is done by "wrapping a linear axis". Setting steps/mm to a value where one turn of the axis equals 360 mm would achieve that. grblHAL has the option of setting max travel for any axis to 0, meaning unlimited travel. By doing so soft limits can be enabled for the other axes. There is also support for manual homing.

My understanding is that GRBL's laser mode already does this in some form.

Yes, by dynamically changing laser power depending on the actual feed rate. PPI pulses the laser instead. IMO PPI is better because it do not suffer from any non-linear relation between PWM output and laser power.

phil-barrett commented 3 years ago

I have seen some results of PPI that show very fine lines burned into paper. Quite impressive level of control it offers.

By the way, I should be receiving more BOBs soon, FedEx has them in transit. I was hoping by Friday but it's looking more like Monday. The wait list is fairly long so I anticipate another sell out. I do have another batch done and waiting for pickup by FedEx.

infamous-panda commented 3 years ago

Nice, I'm on the list.

Just plan on putting the teensy on a test bed connected to a pair of motors and no laser to put it through its paces. If it all works out then I would obviously like to wire it up professionally with the breakout board.

Am I correct that my testing of processing of our gcode is possible without the breakout board?

On Thu, Nov 19, 2020 at 11:40 AM phil-barrett notifications@github.com wrote:

I have seen some results of PPI that show very fine lines burned into paper. Quite impressive level of control it offers.

By the way, I should be receiving more BOBs soon, FedEx has them in transit. I was hoping by Friday but it's looking more like Monday. The wait list is fairly long so I anticipate another sell out. I do have another batch done and waiting for pickup by FedEx.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/terjeio/grblHAL/issues/114#issuecomment-730495575, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM7D7UHRNWOAXYYBP4ORKN3SQVC7DANCNFSM4TWOPRRA .

--

Jonas Concepcion

// www.joncon.net

phil-barrett commented 3 years ago

Yes, it is quite possible. You will need to be careful about the 3.3V pins of the T4.1 - it is NOT 5V tolerant. (there really isn't much middle ground, many Teensy users can testify to that) Also, you might want to use an LPF on the inputs to prevent noise. You will need to change the default grblHAL Step Pulse Width ($0) to get high step rates. By the way, some stepper drivers are marginal at 3.3V so you might want to use an HCT or AHCT line driver to boost to 5V (I use 74AHCT541s). Note that impedance mismatch from breadboards will impact your ability to get to a clean high step pulse rate. I'm doing the next version of the BOB as a 4L board for that reason. Also considering impedance matching if needed.

First time you bring the T4.1 up it will go into alarm state - you will need to invert EStop and Safety Door inputs ($14) if you haven't wired them up (er, down).

HuubBuis commented 3 years ago

The S109 runs on a RAMPS 1.6 shield and on a breadboard. I can't get it running on a (single) step stick driver board I have made for testing. Could be the 3.3 logic voltage I am using. I will do some measurements and swap the processor.

I am done testing. On the Ramps board the driver is always running. In my ESP32 rotary table i can't get it running. On the breadboard SAMD21 it works some times even if I don't change anything between runs.

I googled a lot and found out that that I am not the only one having problems. There are different versions/manufacturers/chip versions of this board. I have decided that new boards will have 5 volt logic in general.

I setup a test to see how much power the S109 driver would deliver. I managed to place the driver backward in his socket. I can't get it running any more. I will order a new one. will be continued...

infamous-panda commented 3 years ago

I have seen some results of PPI that show very fine lines burned into paper. Quite impressive level of control it offers.

By the way, I should be receiving more BOBs soon, FedEx has them in transit. I was hoping by Friday but it's looking more like Monday. The wait list is fairly long so I anticipate another sell out. I do have another batch done and waiting for pickup by FedEx.

Got a note from Tindie that your board was in stock and bought one with all the options. Frustratingly My teensy board has been making the rounds all over New York state post offices over the last week when I actually only live 30 miles from where it shipped from. I have not been able to test it but thought I might as well secure a BOB.

Question. In testing other boards it seems that my bottleneck may be with the sender or the usb pipe being able to supply enough data to the controller.

Would using the ethernet interface have any benefit in this regard?

Is it possible to run gcode locally from an SD card or load it in the teensy's memory?

Also for Grbl Gcode Sender is there an option to add more than X Y Z axis controls and monitor.

phil-barrett commented 3 years ago

You and quite a few others! Got a pile of orders to fulfill. Will ship no later than tomorrow.

Ethernet should help in throughput. But also aggressive buffering on USB helps quite a bit.

There is a capability to run out of local storage on the teensy though it has never been tested and, I suspect, may need a little work. I don't think it has an easy UI. One of those things that has been on my list to figure out.

Also for Grbl Gcode Sender is there an option to add more than X Y Z axis controls and monitor.

I think Terje is the right person answer that. He did post about making it easier to add new modules. I'm sure he would welcome more hands to make that happen.

terjeio commented 3 years ago

Ethernet should help in throughput.

Not neccesarily, there are other bottlnecks as mentioned in comments above that could prevent that.

Is it possible to run gcode locally from an SD card

Yes, the SD card can be used. But you need to be able to send commands to start jobs so not stand-alone until someone writes code for a directly connected screen (possibly via an UART connection) and a UI for that. If you run the same job many times in sequence then a SD card job can be flagged as repeating - pressing the cycle start button will then restart it after it is completed.

or load it in the teensy's memory?

That would require coding. SD card support is already there so not something I would want to do.

Also for Grbl Gcode Sender is there an option to add more than X Y Z axis controls and monitor.

I have some extra controls that I use for a custom sender I made for my CO2 laser: sliders for PPI setting, pulse width and power - check boxes for tube coolant, air assist and exhaust fan. It also has profiles mapped to tool numbers for setting parameters such as PPI and pulse length by a single T command. It is possible to add custom controls, but that would require coding.

IMO what is nice with the sender is that it has a layered structure and uses WPF and MVVM coding patterns in such a way that it is fairly easy to build a custom sender on top of the lower layers.

Making the UI end user configurable and providing a palette of controls for that is something I have been thinking about since I started coding it. A big problem is finding time for all I want to do... More hands would be nice!

infamous-panda commented 3 years ago

If your gcode is a lot of short movements then increasing the planner buffer size could help a lot to get the feed rate up. How the gcode is sent will also play a role. Most grblHAL drivers has a 1024 byte serial input buffer and with "agressive buffering" it is easier to keep the controller busy at all times.

Terjeio.

Is this in reference to the block buffer size in planner H = 36? What would a reasonable max value be ?

Moffy commented 3 years ago

I have been thinking about a controller based around the RT1020, 64Mbytes of RAM, Quad SPI FLASH a USB port and JTAG. Also a series of headers/pins to carry the rest of the pins out, about 50 or so. It makes sense from a DIY perspective because the package is 144 QLFP therefore home solderable. Also the device is very similar to the RT1062 except for the LCD interface and the graphics acceleration. The coding for the board is progressing which would also be easily applicable to any other of the family. Is it a good, or reasonable idea or dead in the water because of the Teensy4.1? Your opinions would be appreciated. The advantage it would have is more I/O, home build and marginally lower cost, but the Teensy is such great value.

phil-barrett commented 3 years ago

Even thought it is more of a competitor to my board, I think you should do it. With each breakout board, the grblHAL world gets bigger. In fact, I believe that it is an exponential increase in size. People see lots of choices and realize it is a real option. Right now we are seeing the early adopters.

It would be great if you could figure out how to put an ethernet phy and host USB on it.

Moffy commented 3 years ago

Even thought it is more of a competitor to my board, I think you should do it. With each breakout board, the grblHAL world gets bigger. In fact, I believe that it is an exponential increase in size. People see lots of choices and realize it is a real option. Right now we are seeing the early adopters.

It would be great if you could figure out how to put an ethernet phy and host USB on it.

Thank you for your generosity of spirit. I am thinking of a simple module that would plug into various base boards as you are using the Teensy. If you wanted Ethernet it would be on the base board along with all the motor drivers, SDcard etc. The USB is OTG so it could handle both Host and Device, but not both at the same time, there is code for both in the NXP SDK. It could be configured through a suitable base board with Ethernet and a serial USB connection, with the USB OTG connector on the processor module. The idea is to make the processor somewhat generic (enough to develop with) and make the base boards specific to the application. If at some stage one wanted to upgrade to the RT1062/RT1064 then the LCD connector would be on the processor board and it should be possible to maintain a pinout compatible with the RT1021 processor board. That's the broad concept anyway.

phil-barrett commented 3 years ago

Not so much generosity as recognition that a rising tide floats all boats.

USB OTG

Does the 1020/1021 support multiple USB interfaces? The 1062 does and the teensy supports it. I have a board coming out that has 2 USB connections - 1 is a host. Lots of issues to consider there so it does not need to be in a first version.

make the processor somewhat generic

Have you looked at MicroMod - Spark Fun's design. PJRC (teensy) looks to be coming out with a 1062 processor module for that. They have pin definitions for it in the Teensyduino core and Paul at PJRC all but confirmed it. I have the SparkFun board and have played with it a bit. Not perfect and is limited in the number pins that can be supported but might be pretty interesting. One thing that appears to be lacking is ethernet support. I keep telling paul he should move to 2x pins on each side. He seems to not be excited about that.

I would be interested in modules that could support 60 or more gpio pins. With the Teensy 4.1 I am starting to feel a little crowded. LCD support is kind of cool but honestly, I think UI should be running on a separate processor and plug in via an I2C interface. The idea is an expandable system that allows products ranging from very low end (think NanoGrbl killer) to very high end giving Masso real competition. grblHAL's interface for that makes a lot of sense to me. If only I had 48 hours in a day.

Moffy commented 3 years ago

The RT1021 only has a single USB port and the RT1050's/RT1060's have two ports. I agree that an LCD interface doesn't excite at present but maybe in the future. I do like the idea of expanded RAM though. You'll only get between 50 and 60 GPIO if SDRAM is used, a lot more if you don't want or need it. Ethernet will use several of those. The MicroMod looks interesting, but too small and limited for IO, too many compromises. It looks like small size is a common goal but I prefer reasonable size and lots of functionality.

infamous-panda commented 3 years ago

First time you bring the T4.1 up it will go into alarm state - you will need to invert EStop and Safety Door inputs ($14) if you haven't wired them up (er, down).

I got a couple runs going with our test code.

Using your 4th Axis firmware I was able to complete our program in 9:27

Our LPC board can do this program in 4:03

Need to look at the buffer options in the firmware I think.

phil-barrett commented 3 years ago

Are you using ioSender? You should enable aggressive buffering if you are.

On Tue, Nov 24, 2020 at 12:24 PM infamous-panda notifications@github.com wrote:

First time you bring the T4.1 up it will go into alarm state - you will need to invert EStop and Safety Door inputs ($14) if you haven't wired them up (er, down).

I got a couple runs going with our test code.

Using your 4th Axis firmware I was able to complete our program in 9:27

Our LPC board can do this program in 4:03

Need to look at the buffer options in the firmware I think.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/terjeio/grblHAL/issues/114#issuecomment-733213955, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD6NUTQICXD3CRRSOO5DAQ3SRQJAZANCNFSM4TWOPRRA .

terjeio commented 3 years ago

@infamous-panda

Need to look at the buffer options in the firmware I think.

https://github.com/terjeio/grblHAL/blob/b7863758a81774dbd8ecd3d31aa2ca2da9676d40/grbl/config.h#L202

Increase until the feed rate no longer improves? And step frequency is below 160KHz?

Perhaps it could be helpful to increase the segment buffer too?

https://github.com/terjeio/grblHAL/blob/b7863758a81774dbd8ecd3d31aa2ca2da9676d40/grbl/config.h#L210

If it is possible to post your settings and an example file I would be happy to look into this.

infamous-panda commented 3 years ago

Yup that's enabled.

On Tue, Nov 24, 2020, 3:41 PM phil-barrett notifications@github.com wrote:

Are you using ioSender? You should enable aggressive buffering if you are.

On Tue, Nov 24, 2020 at 12:24 PM infamous-panda notifications@github.com wrote:

First time you bring the T4.1 up it will go into alarm state - you will need to invert EStop and Safety Door inputs ($14) if you haven't wired them up (er, down).

I got a couple runs going with our test code.

Using your 4th Axis firmware I was able to complete our program in 9:27

Our LPC board can do this program in 4:03

Need to look at the buffer options in the firmware I think.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/terjeio/grblHAL/issues/114#issuecomment-733213955, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AD6NUTQICXD3CRRSOO5DAQ3SRQJAZANCNFSM4TWOPRRA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/terjeio/grblHAL/issues/114#issuecomment-733221943, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM7D7UFUH75IAENEYZGGMMTSRQLBBANCNFSM4TWOPRRA .

infamous-panda commented 3 years ago

Took me the afternoon to figure out how to compile this with arduino.

I just increased the block buffer in planner.h to 1024

With just that I got my time down to 2 minutes. I increased my max acceleration settings and got it down to 1:20 !!! Super excited to get my breakout board and mess around with this some more. I have been struggling to find a way to go faster for the past 6 months!

my benchmark file below

CONTROLLER SPEED TEST.txt

terjeio commented 3 years ago

@infamous-panda What kind of laser do you have? Looks like it could be a CO2 laser to me, if so is it a RF excited tube or a DC one? I am asking because your test file when running fast has very short on times, I wonder if the laser tube/power supply can handle that. My chinese tube/power supply has minimum on (or response) time of around 1 ms, running your test file at about 30000 mm/min I get on times around 400 µs - 2 and a fraction of a PWM pulse at 5 Khz...

When using laser mode ($32=1) and M4 you can get rid of the S0/S1000 commands on every line - set the power only when a change is needed, G0 moves are with the laser off anyway:

G92 X0 A0 
G21
G90
M4S1000
G0X0A0
F100000.0
G0 A1.0000 X0.0014
G1 A1.2292 X0.0014
G0 A2.1465 X0.0030
G1 A2.3757 X0.0030
...

-> less data to transfer, test file became around 500 Kb smaller.