[fretman_2]

I had the aviation connectors on my Shapeoko and they worked fine, but it wasn't in constant use either. I just want to hook up the thing and not have to worry about it...LOL.

I used the 4 pin aviation connectors from ebay on my last build and I think they are great, they screw together so they won't accidentally get disconnected and short of getting them wet I think they should be no issue with contamination. Being able to easily swap to different controllers to see if it is a wiring/motor issue or a controller issue is nice. There have been times when I have moved my machines around and having everything hard wired was a bit of a pain, if you control box is part of you machine and you just need to disconnect a usb or serial cable I guess this is less an issue. I have 3 different controllers, I am planning on wiring the other 2 in the same configuration so I can swap them out if needed.

[fretman_2]

Lookie what I got...the PS is 48v 10A.

I purchased only two of the drivers, will get the final two next week after I get some gig $$.

Attachment 327778
Attachment 327780

[fretman_2]

Regarding hooking up my Arduino Uno to the M542T...what do I do with the enable? I've seen some tutorials leave it out only hooking up pulse and dir. One person on the Shapeoko forum said to cain the enable from the Arduino to each driver. Tnx,

[fretman_2]

UPDATE...all I had to do was look at the datasheet for the driver. Enable on the driver is usually left unconnected. Unconnected is on or enabled.

[Schuimpge]

Hello Fretman..looks good so far, will be closely following your thread as I'm going pretty much the same route with electronics and software.
Cheers
Luc

[fretman_2]

Very coo! Hope I get it right!

Hello Fretman..looks good so far, will be closely following your thread as I'm going pretty much the same route with electronics and software.
Cheers
Luc

- - - Updated - - -

I noticed a switch on the M542T for full or half current mode. Which do I use and why???

[fretman_2]

What's the benefit of setting the pulse/rev settings on the M542T driver vs setting them in GRBL? Maybe I have a huge misunderstanding about that. With the gShield I was using, I don't remember setting any dip switches...I set the steps/rev in GRBL setup.

[louieatienza]

Very coo! Hope I get it right!



- - - Updated - - -

I noticed a switch on the M542T for full or half current mode. Which do I use and why???

Is that for idle current? Then you'd want to set that to half; this keeps the drive from using full current when not moving, keeping the motors a lot cooler.

[fretman_2]

Not sure...the supplier of the driver said to set it to full current. Not sure if it ties in with the enable function. I guess I'll find out of the motors run hot on idle.

Tnx,

Is that for idle current? Then you'd want to set that to half; this keeps the drive from using full current when not moving, keeping the motors a lot cooler.

[109jb]

Is that for idle current? Then you'd want to set that to half; this keeps the drive from using full current when not moving, keeping the motors a lot cooler.

That depends on what kind of axis he has. If driven by a screw then 1/2 current is fine. If a rack, or similar, then the motor has to withstand any attempt to back drive the axis directly. For those I would leave idle current at full power.

People worry way too much about motor heat. They touch their stepper motors and because they are a little warm they get worried. Well, they are made to run pretty darn hot. Most have maximum case temperature ratings of about 100 deg Celsius or more. That's boiling water temperature and will burn you quickly. A warm motor is nothing to worry about.

[109jb]

What's the benefit of setting the pulse/rev settings on the M542T driver vs setting them in GRBL? Maybe I have a huge misunderstanding about that. With the gShield I was using, I don't remember setting any dip switches...I set the steps/rev in GRBL setup.

You have to set BOTH the driver and to control software to the same pulses/rev. The driver has no idea what GRBL is set to, and GRBL has no idea what the driver is set to. Finally, neither the driver or GRBL know what you want to set them to.

[fretman_2]

All axes are driven by screws. I can certainly start out at 1/2 current and see if there are missed steps. I'm still a little confused though. I'm setting the driver current to 2.8A which is the max current of the motors, then setting the current settings on the driver to 1/2 current. Does this mean that I'm really only supplying the motors 1.4A of current?

That depends on what kind of axis he has. If driven by a screw then 1/2 current is fine. If a rack, or similar, then the motor has to withstand any attempt to back drive the axis directly. For those I would leave idle current at full power. People worry way too much about motor heat. They touch their stepper motors and because they are a little warm they get worried. Well, they are made to run pretty darn hot. Most have maximum case temperature ratings of about 100 deg Celsius or more. That's boiling water temperature and will burn you quickly. A warm motor is nothing to worry about.

Cool...thanks for the explanation!

You have to set BOTH the driver and to control software to the same pulses/rev. The driver has no idea what GRBL is set to, and GRBL has no idea what the driver is set to. Finally, neither the driver or GRBL know what you want to set them to.

[fretman_2]

Got a computer case to house my electronics.

[fretman_2]

Started arraigning things within the case. Power supply, two drivers and the Arduino Uno clone. I have two more drivers on the way. The parts are sitting on a plexi glass sheet which I'm using as a template, Once I'm happy with the arraignment...I'll transfer the hole pattern to a steel sheet.



This is a shot of the Arduino Uno clone that I'll be using as the CNC controller. This board communicates with the computer via the USB port. It was just a little over 5 bucks on eBay. The only real difference, in terms of functionality, between it and the real Uno board is the USB communications chip. This clone uses the CH340 chip which has its own driver. I was able to burn GRBL v9j onto it once the driver was installed, It communicated perfectly with the computer and the Universal GCode Sender that I've been using. Solder joints on the back of the board could use a little more solder, but I won't be stressing the board too much anyway. The board will only control three axes, but I'll send the single Y output to two drivers for the X axis.

[109jb]

...The only real difference, in terms of functionality, between it and the real Uno board is the USB communications chip. This clone uses the CH340 chip which has its own driver.

I am a GRBL user myself. I think it is a great setup, but I have to warn you that using a clone with the CH340G chip is not advised. A while back I identified a problem with the CH340G chip and did a lot of testing. In a nutshell, the CH340G chip has an issue where data can be lost in transmission to the clone. It doesn't happen often, but when it does it could result in a crash. You can read more about this in the GRBL WIKI on github at this link https://github.com/grbl/grbl/wiki/Known-Bugs

In a nutshell, there is no fix for the CH340G, but there is a fix for the 16U2 usb/serial chip found on some clones and the genuine UNO. The 16U2 chip is probably fine without modification as long as you use 115200 baud rate setting, but there is a new firmware you can flash to it to fix all problems. The ch340 has the errors at any reasonable baud rate, and can't be fixed. I wound up replacing my clones that had the CH340 with clones with the 16U2 because of this problem.

[fretman_2]

Wow...I do have an original Uno. So no fix for the CH340...dang.

I am a GRBL user myself. I think it is a great setup, but I have to warn you that using a clone with the CH340G chip is not advised. A while back I identified a problem with the CH340G chip and did a lot of testing. In a nutshell, the CH340G chip has an issue where data can be lost in transmission to the clone. It doesn't happen often, but when it does it could result in a crash. You can read more about this in the GRBL WIKI on github at this link https://github.com/grbl/grbl/wiki/Known-Bugs

In a nutshell, there is no fix for the CH340G, but there is a fix for the 16U2 usb/serial chip found on some clones and the genuine UNO. The 16U2 chip is probably fine without modification as long as you use 115200 baud rate setting, but there is a new firmware you can flash to it to fix all problems. The ch340 has the errors at any reasonable baud rate, and can't be fixed. I wound up replacing my clones that had the CH340 with clones with the 16U2 because of this problem.

[109jb]

Yeah. I was using a NANO clone that uses the same CH340 chip. I wound up replacing the nano with an Uno clone with a 16U2 and flashing the updated firmware. The error doesn't happen often, but is not predictable as to when it will happen. Luckily I found the problem when doing a dry run on a 3D milling test. I had the step-over on parallel passes set for 0.001" step-over and got an error in my streaming program about 30,000 lines in on one dry run. I re-ran it and it completed successfully, but I started investigating. At first, I thought it was probably my interface program that I wrote myself. I set GRBL to echo the received lines and set up a sniffer program for the serial port and found that when the error occurred, the line was sent correctly from the PC, but GRBL echoed back incorrectly. I then did a loop back test where the lines were sent and immediately looped back to the PC, taking the Arduino out of the loop and the error was there. That test confirmed it had something to do with the CH340. At this time another GRBL user got involved and he was able to replicate it on the 16u2, but not at 115,200 baud. He was able to find the code for the firmware for the 16u2 and made some modification that fixed it on the 16u2. The reason there isn't a fix for the ch340G is because the firmware code for that chip isn't available. I actually e-mailed the company that makes it asking for either a fix, or the firmware so that it could be modified, but never got a response. Basically what happens is as follows:

2 consecutive lines like:
G1 X1.2345 Y9.8765 Z4.5678
G1 X2.3456 Y8.7654 Z5.6789

might only get through as
G1 X1.2345 Y9.8754 Z5.6789

where the text in bold I is just dropped. The above example would not generate an error, but the machine would go to the wrong place. It is random what text gets dropped, and sometimes it still looks like a valid command to GRBL, and other times it doesn't and generates an error.

Alex Holden on the GRBL site is the one who fixed the 16u2 firmware and in his testing he found that at 115,200 baud the 16u2 seems to work fine without modification. I would still recommend re-flashing the 16u2 with his modified firmware. I have been using it since he posted it and it has been flawless. I tested his modified firmware using a 1 million line g-code file and could generate an error in about 4 days of running in a test setup, looping through the file over and over and over.

[fretman_2]

109jb...awesome investigatory work! Did I read that with the CH340 comms chip you had the problem at 115200 baud, but not at 76800, or 250000 baud??

I am a GRBL user myself. I think it is a great setup, but I have to warn you that using a clone with the CH340G chip is not advised. A while back I identified a problem with the CH340G chip and did a lot of testing. In a nutshell, the CH340G chip has an issue where data can be lost in transmission to the clone. It doesn't happen often, but when it does it could result in a crash. You can read more about this in the GRBL WIKI on github at this link https://github.com/grbl/grbl/wiki/Known-Bugs

In a nutshell, there is no fix for the CH340G, but there is a fix for the 16U2 usb/serial chip found on some clones and the genuine UNO. The 16U2 chip is probably fine without modification as long as you use 115200 baud rate setting, but there is a new firmware you can flash to it to fix all problems. The ch340 has the errors at any reasonable baud rate, and can't be fixed. I wound up replacing my clones that had the CH340 with clones with the 16U2 because of this problem.

[fretman_2]

109jb...I just ordered one of the clones with the 16U2 comms chip. That should do it. I just wanted to have a backup microcontroller.

Yeah. I was using a NANO clone that uses the same CH340 chip. I wound up replacing the nano with an Uno clone with a 16U2 and flashing the updated firmware. The error doesn't happen often, but is not predictable as to when it will happen. Luckily I found the problem when doing a dry run on a 3D milling test. I had the step-over on parallel passes set for 0.001" step-over and got an error in my streaming program about 30,000 lines in on one dry run. I re-ran it and it completed successfully, but I started investigating. At first, I thought it was probably my interface program that I wrote myself. I set GRBL to echo the received lines and set up a sniffer program for the serial port and found that when the error occurred, the line was sent correctly from the PC, but GRBL echoed back incorrectly. I then did a loop back test where the lines were sent and immediately looped back to the PC, taking the Arduino out of the loop and the error was there. That test confirmed it had something to do with the CH340. At this time another GRBL user got involved and he was able to replicate it on the 16u2, but not at 115,200 baud. He was able to find the code for the firmware for the 16u2 and made some modification that fixed it on the 16u2. The reason there isn't a fix for the ch340G is because the firmware code for that chip isn't available. I actually e-mailed the company that makes it asking for either a fix, or the firmware so that it could be modified, but never got a response. Basically what happens is as follows:

2 consecutive lines like:
G1 X1.2345 Y9.8765 Z4.5678
G1 X2.3456 Y8.7654 Z5.6789

might only get through as
G1 X1.2345 Y9.8754 Z5.6789

where the text in bold I is just dropped. The above example would not generate an error, but the machine would go to the wrong place. It is random what text gets dropped, and sometimes it still looks like a valid command to GRBL, and other times it doesn't and generates an error.

Alex Holden on the GRBL site is the one who fixed the 16u2 firmware and in his testing he found that at 115,200 baud the 16u2 seems to work fine without modification. I would still recommend re-flashing the 16u2 with his modified firmware. I have been using it since he posted it and it has been flawless. I tested his modified firmware using a 1 million line g-code file and could generate an error in about 4 days of running in a test setup, looping through the file over and over and over.

[fretman_2]

A short video of Y axis movement. Controller is a clone Arduino Uno with the ATmega16U2 comms chip. Drivers are M542T from stepperonline.com. I'm only running 45v at this time but will push it to 47v which will be 3v under the 50v max of the drivers. A few more details...lead screws are 1/2-10 5 start. Nema23 269oz steppers. Power supply is 48v 10.4A.

Both Y drivers share the same Y axis signals from the Arduino. Here I'm only moving around 6" per jog and rapids are 100ipm. I didn't want to push it any higher at this time.

Bearing holders are MDF at this time and one of the first things I'll cut is new ones from HDPE.

I hope to test all axes this weekend and will update with a new vid.