with steppers idle they are under power , thats how they appear in a locked position i.e you cant move the shaft
hence they become hot as all coils are activated to hold position
-----Original Message----- From: jet
Sent: Friday, September 07, 2012 6:24 PM
To: lasersaur@googlegroups.com
Subject: Re: [lasersaur] Yet Another LasaurApp Update, v12.08f
On 2012-09-07 12:57, Stefan Hechenberger wrote:
> I also think David has a good point. If you overdrive your steppers with
> too much current the drivers may very well show the behavior you are
> describing. The 203V have over-temp protection and switch off when
Just to be clear, if the board is idle, that is there is no job being
executed, the steppers are not under power, correct?
This was a huge PITA on the MakerBot, it'd be sitting there doing
nothing but the steppers would be locked down and under power. That's
what mine seem to be doing: there are no commands being executed but
they are powered on and I can't move the chassis by hand.
also forgot to add , stepper motors are designed to be under power , and therefore generate heat
the option is not to allow them to become over hot , this is shown easily , if the drive is left stationary for say 4 mins , they should be
warm to touch , but not over hot where you cannot bear to touch ... but they can withstand heat ..
if they show a tendancy to be over hot then it's normaly the fact that the motors are drawing too much current , so therefore change the resistors to bring the current down and
reduce heat
-----Original Message----- From: jet
Sent: Friday, September 07, 2012 6:24 PM
To: lasersaur@googlegroups.com
Subject: Re: [lasersaur] Yet Another LasaurApp Update, v12.08f
On 2012-09-07 12:57, Stefan Hechenberger wrote:
> I also think David has a good point. If you overdrive your steppers with
> too much current the drivers may very well show the behavior you are
> describing. The 203V have over-temp protection and switch off when
Just to be clear, if the board is idle, that is there is no job being
executed, the steppers are not under power, correct?
This was a huge PITA on the MakerBot, it'd be sitting there doing
nothing but the steppers would be locked down and under power. That's
what mine seem to be doing: there are no commands being executed but
they are powered on and I can't move the chassis by hand.
> > power off error
> Typically I would guess this is a shielding problem on the line attached
> to rel/vrel. Please try to verify this by connecting these inputs
> directly with a jumper cable.
Yup, that fixes it. Not sure why this wasn't a problem before, but it's easy to add the ground to the common ground.
Maybe double check the shield leads. About a month ago we updated the wiring diagram because some of the shielding was connected to the ground through 10k resistors which is probably not optimal.
>> > power off error
>> Typically I would guess this is a shielding problem on the line attached
>> to rel/vrel. Please try to verify this by connecting these inputs
>> directly with a jumper cable.
> Yup, that fixes it. Not sure why this wasn't a problem before, but it's
> easy to add the ground to the common ground.
Is there a place to get previous releases of the lasaurapp? I just
switched to 12.08f and now the machine gives me the "Limit Hit" errors. I
flashed the grbl with the 127.0.0.1:4444/flash_firmware link.
Jamie and I were using 12.06? i think? today with no problems. I had a
system crash and need to get my win7 laptop setup to cut.
On Thu, Sep 6, 2012 at 4:15 PM, jet <allartbu...@gmail.com> wrote:
> Previously they weren't getting enough power to turn properly. I read the
> Gecko and Lin manuals and changed the resistors to increase the amount of
> amps available.
> In prior releases I could easily run the table without anything locking up
> and geting the "power off" messages.
> I'll try and do some printf debugging and figure out exactly what's going
> on. It looks like the rest of 2012 is "debug stepper controllers tasks".
> :-)
> On 2012-09-06 18:38, David Armstrong wrote:
>> i’d guess a possible problem your having is the stepper drivers are
>> switching off perhaps , due to drawing too much current , and therefore
>> they are shutting down
>> once the temp reduces then they will reset ...
>> have you checked your current draw ? , it’s normal for steppers to get
>> hot , and surprisingly they are designed to handle it , but not to the
>> point of being able to cook eggs ...
>> remember steppers actualy draw more current when stationary than when
>> moving , so if they are idle for a long period they can get pretty hot .
>> most drivers can handle this by going into a semi operational state to
>> save power ... depends on what stepper drivers you are using
>> so if this is happening it can result in intermittent operations .
>> if the motors are becoming hot very quickly from cold then i’d suspect
>> you are driving them to hard , so reduce current draw and perhaps
>> voltage too
>> running at too high microstepping can also result in similar results but
>> for different reasons .
>> or you have a some noisy wiring picking up rubbish which is crashing the
>> system
>> *From:* jet townsend <mailto:allartbu...@gmail.com>
>> *Sent:* Thursday, September 06, 2012 11:15 PM
>> *To:* lasersaur@googlegroups.com <mailto:lasersaur@**googlegroups.com<lasersaur@googlegroups.com>
>> *Subject:* Re: [lasersaur] Yet Another LasaurApp Update, v12.08e
>> Hm, there's a problem that I thought was speed related but happens on
>> all speeds. The head gets to roughly X100 Y100 then everything stops
>> and I get a power Off message. If I'm on high speed it just happens
>> more quickly, but it looks to be in the same place.
>> At the same time, all of the switches are clear but the steppers are
>> almost too hot to touch.
>> On Sun, Aug 26, 2012 at 8:31 PM, Stefan Hechenberger <ste...@nortd.com
>> <mailto:ste...@nortd.com>> wrote:
>> We are moving quickly. Here is another release candidate. Please
>> test! I feel pretty confident about this one because we had the time
>> to run it quite extensively. I finally got USB working in VirtualBox
>> and was able to test on Windows and Linux in addition to OSX. We
>> also tested on the Beaglebone. All platforms ran the gantry
>> flawlessly so far.
>> CHANGES are as follows:
>> - serial communication completely rewritten
>> - more robust flow control
>> - forward error correction and error reporting
>> - faster speeds, now runs at 57600 bps
>> - firmware bugfixes in serial module dealing with concurrency
>> issues
>> - workaround for pyserial bugs
>> - additons to the protocol, see:
>> http://labs.nortd.com/__**lasersaur/manual/gcode<http://labs.nortd.com/__lasersaur/manual/gcode>
>> - better optimizations in gcode generation
>> - bugfixes in com port auto-configuration on windows and linux
>> I can talk more about the new serial communication code. The details
>> are actually quite interesting. Since the serial interrupts fire so
>> frequently the slightest concurrency flaws can cause quite the scene.
> Is there a place to get previous releases of the lasaurapp? I just
> switched to 12.08f and now the machine gives me the "Limit Hit" errors.
> I flashed the grbl with the 127.0.0.1:4444/flash_firmware
> <http://127.0.0.1:4444/flash_firmware> link.
> Jamie and I were using 12.06? i think? today with no problems. I had a
> system crash and need to get my win7 laptop setup to cut.
> On Thu, Sep 6, 2012 at 4:15 PM, jet <allartbu...@gmail.com
> <mailto:allartbu...@gmail.com>> wrote:
> Previously they weren't getting enough power to turn properly. I
> read the Gecko and Lin manuals and changed the resistors to increase
> the amount of amps available.
> In prior releases I could easily run the table without anything
> locking up and geting the "power off" messages.
> I'll try and do some printf debugging and figure out exactly what's
> going on. It looks like the rest of 2012 is "debug stepper
> controllers tasks". :-)
> On 2012-09-06 18:38, David Armstrong wrote:
> i’d guess a possible problem your having is the stepper drivers are
> switching off perhaps , due to drawing too much current , and
> therefore
> they are shutting down
> once the temp reduces then they will reset ...
> have you checked your current draw ? , it’s normal for steppers
> to get
> hot , and surprisingly they are designed to handle it , but not
> to the
> point of being able to cook eggs ...
> remember steppers actualy draw more current when stationary than
> when
> moving , so if they are idle for a long period they can get
> pretty hot .
> most drivers can handle this by going into a semi operational
> state to
> save power ... depends on what stepper drivers you are using
> so if this is happening it can result in intermittent operations .
> if the motors are becoming hot very quickly from cold then i’d
> suspect
> you are driving them to hard , so reduce current draw and perhaps
> voltage too
> running at too high microstepping can also result in similar
> results but
> for different reasons .
> or you have a some noisy wiring picking up rubbish which is
> crashing the
> system
> *From:* jet townsend <mailto:allartbu...@gmail.com
> <mailto:allartbu...@gmail.com>>
> *Sent:* Thursday, September 06, 2012 11:15 PM
> *To:* lasersaur@googlegroups.com
> <mailto:lasersaur@googlegroups.com>
> <mailto:lasersaur@__googlegroups.com
> <mailto:lasersaur@googlegroups.com>>
> *Subject:* Re: [lasersaur] Yet Another LasaurApp Update, v12.08e
> Hm, there's a problem that I thought was speed related but
> happens on
> all speeds. The head gets to roughly X100 Y100 then everything
> stops
> and I get a power Off message. If I'm on high speed it just happens
> more quickly, but it looks to be in the same place.
> At the same time, all of the switches are clear but the steppers are
> almost too hot to touch.
> On Sun, Aug 26, 2012 at 8:31 PM, Stefan Hechenberger
> <ste...@nortd.com <mailto:ste...@nortd.com>
> <mailto:ste...@nortd.com <mailto:ste...@nortd.com>>> wrote:
> We are moving quickly. Here is another release candidate.
> Please
> test! I feel pretty confident about this one because we had
> the time
> to run it quite extensively. I finally got USB working in
> VirtualBox
> and was able to test on Windows and Linux in addition to
> OSX. We
> also tested on the Beaglebone. All platforms ran the gantry
> flawlessly so far.
> CHANGES are as follows:
> - serial communication completely rewritten
> - more robust flow control
> - forward error correction and error reporting
> - faster speeds, now runs at 57600 bps
> - firmware bugfixes in serial module dealing with
> concurrency issues
> - workaround for pyserial bugs
> - additons to the protocol, see:
> http://labs.nortd.com/____lasersaur/manual/gcode > <http://labs.nortd.com/__lasersaur/manual/gcode>
> I can talk more about the new serial communication code.
> The details
> are actually quite interesting. Since the serial interrupts
> fire so
> frequently the slightest concurrency flaws can cause quite
> the scene.
>> Is there a place to get previous releases of the lasaurapp? I just
>> switched to 12.08f and now the machine gives me the "Limit Hit" errors.
>> I flashed the grbl with the 127.0.0.1:4444/flash_firmware
>> <http://127.0.0.1:4444/flash_**firmware<http://127.0.0.1:4444/flash_firmware>>
>> link.
>> Jamie and I were using 12.06? i think? today with no problems. I had a
>> system crash and need to get my win7 laptop setup to cut.
>> On Thu, Sep 6, 2012 at 4:15 PM, jet <allartbu...@gmail.com
>> <mailto:allartbu...@gmail.com>**> wrote:
>> Previously they weren't getting enough power to turn properly. I
>> read the Gecko and Lin manuals and changed the resistors to increase
>> the amount of amps available.
>> In prior releases I could easily run the table without anything
>> locking up and geting the "power off" messages.
>> I'll try and do some printf debugging and figure out exactly what's
>> going on. It looks like the rest of 2012 is "debug stepper
>> controllers tasks". :-)
>> On 2012-09-06 18:38, David Armstrong wrote:
>> i’d guess a possible problem your having is the stepper drivers
>> are
>> switching off perhaps , due to drawing too much current , and
>> therefore
>> they are shutting down
>> once the temp reduces then they will reset ...
>> have you checked your current draw ? , it’s normal for steppers
>> to get
>> hot , and surprisingly they are designed to handle it , but not
>> to the
>> point of being able to cook eggs ...
>> remember steppers actualy draw more current when stationary than
>> when
>> moving , so if they are idle for a long period they can get
>> pretty hot .
>> most drivers can handle this by going into a semi operational
>> state to
>> save power ... depends on what stepper drivers you are using
>> so if this is happening it can result in intermittent operations .
>> if the motors are becoming hot very quickly from cold then i’d
>> suspect
>> you are driving them to hard , so reduce current draw and perhaps
>> voltage too
>> running at too high microstepping can also result in similar
>> results but
>> for different reasons .
>> or you have a some noisy wiring picking up rubbish which is
>> crashing the
>> system
>> *From:* jet townsend <mailto:allartbu...@gmail.com
>> <mailto:allartbu...@gmail.com>**>
>> *Sent:* Thursday, September 06, 2012 11:15 PM
>> *To:* lasersaur@googlegroups.com
>> <mailto:lasersaur@**googlegroups.com <lasersaur@googlegroups.com>
>> *Subject:* Re: [lasersaur] Yet Another LasaurApp Update, v12.08e
>> Hm, there's a problem that I thought was speed related but
>> happens on
>> all speeds. The head gets to roughly X100 Y100 then everything
>> stops
>> and I get a power Off message. If I'm on high speed it just
>> happens
>> more quickly, but it looks to be in the same place.
>> At the same time, all of the switches are clear but the steppers
>> are
>> almost too hot to touch.
>> On Sun, Aug 26, 2012 at 8:31 PM, Stefan Hechenberger
>> <ste...@nortd.com <mailto:ste...@nortd.com>
>> <mailto:ste...@nortd.com <mailto:ste...@nortd.com>>> wrote:
>> We are moving quickly. Here is another release candidate.
>> Please
>> test! I feel pretty confident about this one because we had
>> the time
>> to run it quite extensively. I finally got USB working in
>> VirtualBox
>> and was able to test on Windows and Linux in addition to
>> OSX. We
>> also tested on the Beaglebone. All platforms ran the gantry
>> flawlessly so far.
>> - better optimizations in gcode generation
>> - bugfixes in com port auto-configuration on windows and
>> linux
>> I can talk more about the new serial communication code.
>> The details
>> are actually quite interesting. Since the serial interrupts
>> fire so
>> frequently the slightest concurrency flaws can cause quite
>> the scene.
On Sat, Sep 8, 2012 at 2:57 AM, Stefan Hechenberger <ste...@nortd.com> wrote:
> From top to bottom the pins are even if the labels may say something else:
> A5, A4, 3.3V, GND
> Also be careful when controlling the valve solenoid. They tend to have a
> pretty strong inductive kickback (30-300V). And also make sure you don't use
> any relays that draw more than the atmega328 approved 40mA. Feel free to
> start a new thread about this circuitry. I have recently shopped around for
> components regarding this and can brain dump if you want.
You would need to drive the solenoid valves using a MOSFET (or BJT),
not directly from the AVR.
You could use a small MOSFET/BJT to switch a relay coil which then
switches the solenoid valve, but assuming that the solenoid valves run
from the 24V DC rail (not 120VAC) personally I would switch them
directly from the microcontroller using an appropriately rated power
FET. Personally I dislike the use of electromechanical, low-tech,
noisy, moving relays when solid-state silicon can easily and cheaply
do the same job without a relay. And, yes, you'll want a
reverse-biased diode across the coil (either in the solenoid valve or
in the relay) as usual to protect the transistor.
You would, presumably, need a small extra PCB connected to the A4/A5
assist gas solenoid header on the board which controls those
solenoids.
> On Sat, Sep 8, 2012 at 2:57 AM, Stefan Hechenberger <ste...@nortd.com> wrote:
>> From top to bottom the pins are even if the labels may say something else:
>> A5, A4, 3.3V, GND
>> Also be careful when controlling the valve solenoid. They tend to have a
>> pretty strong inductive kickback (30-300V). And also make sure you don't use
>> any relays that draw more than the atmega328 approved 40mA. Feel free to
>> start a new thread about this circuitry. I have recently shopped around for
>> components regarding this and can brain dump if you want.
> You would need to drive the solenoid valves using a MOSFET (or BJT),
> not directly from the AVR.
> You could use a small MOSFET/BJT to switch a relay coil which then
> switches the solenoid valve, but assuming that the solenoid valves run
> from the 24V DC rail (not 120VAC) personally I would switch them
> directly from the microcontroller using an appropriately rated power
> FET. Personally I dislike the use of electromechanical, low-tech,
> noisy, moving relays when solid-state silicon can easily and cheaply
> do the same job without a relay. And, yes, you'll want a
> reverse-biased diode across the coil (either in the solenoid valve or
> in the relay) as usual to protect the transistor.
> You would, presumably, need a small extra PCB connected to the A4/A5
> assist gas solenoid header on the board which controls those
> solenoids.
Running air assist continuously is fine. It just means that the compressor will run more. Also if you use nitrogen assist you will find yourself turning the gas on and off a lot.
> Sorry - recently started a build, so I might have missed this if discussed earlier.
> Is there a reason to not run air assist continuously while running a cut / etch job?
> -- -- -- -- --- -- -- -- --
> Erik Moon
> On Sep 11, 2012, at 1:12, Luke Weston <reindeerfloti...@gmail.com> wrote:
>> On Sat, Sep 8, 2012 at 2:57 AM, Stefan Hechenberger <ste...@nortd.com> wrote:
>>> From top to bottom the pins are even if the labels may say something else:
>>> A5, A4, 3.3V, GND
>>> Also be careful when controlling the valve solenoid. They tend to have a
>>> pretty strong inductive kickback (30-300V). And also make sure you don't use
>>> any relays that draw more than the atmega328 approved 40mA. Feel free to
>>> start a new thread about this circuitry. I have recently shopped around for
>>> components regarding this and can brain dump if you want.
>> You would need to drive the solenoid valves using a MOSFET (or BJT),
>> not directly from the AVR.
>> You could use a small MOSFET/BJT to switch a relay coil which then
>> switches the solenoid valve, but assuming that the solenoid valves run
>> from the 24V DC rail (not 120VAC) personally I would switch them
>> directly from the microcontroller using an appropriately rated power
>> FET. Personally I dislike the use of electromechanical, low-tech,
>> noisy, moving relays when solid-state silicon can easily and cheaply
>> do the same job without a relay. And, yes, you'll want a
>> reverse-biased diode across the coil (either in the solenoid valve or
>> in the relay) as usual to protect the transistor.
>> You would, presumably, need a small extra PCB connected to the A4/A5
>> assist gas solenoid header on the board which controls those
>> solenoids.
Craig, I don't really have a good answer to make v12.08f work for you. One way would be to just wait and see if anybody else runs into similar problems.
I still think there is a small chance it's a line noise issue. The v12.08f firmware has a slightly changed acceleration profile. It's possible that this is enough to cause some issues if you were just under the threshold before. One way to find out very quickly is to jumper the sensor inputs.
> On Thu, Sep 6, 2012 at 4:15 PM, jet <allartbu...@gmail.com
> <mailto:allartbu...@gmail.com>
> <mailto:allartbu...@gmail.com <mailto:allartbu...@gmail.com>>__>
> wrote:
> Previously they weren't getting enough power to turn
> properly. I
> read the Gecko and Lin manuals and changed the resistors to
> increase
> the amount of amps available.
> In prior releases I could easily run the table without anything
> locking up and geting the "power off" messages.
> I'll try and do some printf debugging and figure out
> exactly what's
> going on. It looks like the rest of 2012 is "debug stepper
> controllers tasks". :-)
> On 2012-09-06 18:38, David Armstrong wrote:
> i’d guess a possible problem your having is the stepper
> drivers are
> switching off perhaps , due to drawing too much current
> , and
> therefore
> they are shutting down
> once the temp reduces then they will reset ...
> have you checked your current draw ? , it’s normal for
> steppers
> to get
> hot , and surprisingly they are designed to handle it ,
> but not
> to the
> point of being able to cook eggs ...
> remember steppers actualy draw more current when
> stationary than
> when
> moving , so if they are idle for a long period they can get
> pretty hot .
> most drivers can handle this by going into a semi
> operational
> state to
> save power ... depends on what stepper drivers you are
> using
> so if this is happening it can result in intermittent
> operations .
> if the motors are becoming hot very quickly from cold
> then i’d
> suspect
> you are driving them to hard , so reduce current draw
> and perhaps
> voltage too
> running at too high microstepping can also result in
> similar
> results but
> for different reasons .
> or you have a some noisy wiring picking up rubbish which is
> crashing the
> system
> *From:* jet townsend <mailto:allartbu...@gmail.com
> <mailto:allartbu...@gmail.com>
> <mailto:allartbu...@gmail.com
> <mailto:allartbu...@gmail.com>>__>
> *Sent:* Thursday, September 06, 2012 11:15 PM
> *To:* lasersaur@googlegroups.com
> <mailto:lasersaur@googlegroups.com>
> <mailto:lasersaur@__googlegroups.com
> <mailto:lasersaur@googlegroups.com>>
> <mailto:lasersaur@
> <mailto:lasersaur@>__googlegrou__ps.com <http://googlegroups.com>
> Hm, there's a problem that I thought was speed related but
> happens on
> all speeds. The head gets to roughly X100 Y100 then
> everything
> stops
> and I get a power Off message. If I'm on high speed it
> just happens
> more quickly, but it looks to be in the same place.
> At the same time, all of the switches are clear but the
> steppers are
> almost too hot to touch.
> On Sun, Aug 26, 2012 at 8:31 PM, Stefan Hechenberger
> <ste...@nortd.com <mailto:ste...@nortd.com>
> <mailto:ste...@nortd.com <mailto:ste...@nortd.com>>
> <mailto:ste...@nortd.com <mailto:ste...@nortd.com>
> <mailto:ste...@nortd.com <mailto:ste...@nortd.com>>>> wrote:
> We are moving quickly. Here is another release
> candidate.
> Please
> test! I feel pretty confident about this one
> because we had
> the time
> to run it quite extensively. I finally got USB
> working in
> VirtualBox
> and was able to test on Windows and Linux in
> addition to
> OSX. We
> also tested on the Beaglebone. All platforms ran
> the gantry
> flawlessly so far.
Habe Mühe mit dem Runterladen - sagt mir immer "this is not the page you
are looking for. Und wenn ich das Teil direkt runterlade, dann ist es nur
21 K gross. Stimmt was nicht mit Github?
> We are moving quickly. Here is another release candidate. Please test! I
> feel pretty confident about this one because we had the time to run it
> quite extensively. I finally got USB working in VirtualBox and was able to
> test on Windows and Linux in addition to OSX. We also tested on the
> Beaglebone. All platforms ran the gantry flawlessly so far.
> CHANGES are as follows:
> - serial communication completely rewritten
> - more robust flow control
> - forward error correction and error reporting
> - faster speeds, now runs at 57600 bps
> - firmware bugfixes in serial module dealing with concurrency issues
> - workaround for pyserial bugs
> - additons to the protocol, see:
> http://labs.nortd.com/**lasersaur/manual/gcode<http://labs.nortd.com/lasersaur/manual/gcode>
> - better optimizations in gcode generation
> - bugfixes in com port auto-configuration on windows and linux
> I can talk more about the new serial communication code. The details are
> actually quite interesting. Since the serial interrupts fire so frequently
> the slightest concurrency flaws can cause quite the scene.
> Habe M he mit dem Runterladen - sagt mir immer "this is not the page you
> are looking for. Und wenn ich das Teil direkt runterlade, dann ist es
> nur 21 K gross. Stimmt was nicht mit Github?
> Beste Gr sse
> Mischa
> 2012/8/27 Stefan Hechenberger <ste...@nortd.com <mailto:ste...@nortd.com>>
> We are moving quickly. Here is another release candidate. Please
> test! I feel pretty confident about this one because we had the time
> to run it quite extensively. I finally got USB working in VirtualBox
> and was able to test on Windows and Linux in addition to OSX. We
> also tested on the Beaglebone. All platforms ran the gantry
> flawlessly so far.
> CHANGES are as follows:
> - serial communication completely rewritten
> - more robust flow control
> - forward error correction and error reporting
> - faster speeds, now runs at 57600 bps
> - firmware bugfixes in serial module dealing with concurrency issues
> - workaround for pyserial bugs
> - additons to the protocol, see:
> http://labs.nortd.com/__lasersaur/manual/gcode > <http://labs.nortd.com/lasersaur/manual/gcode>
> - better optimizations in gcode generation
> - bugfixes in com port auto-configuration on windows and linux
> I can talk more about the new serial communication code. The details
> are actually quite interesting. Since the serial interrupts fire so
> frequently the slightest concurrency flaws can cause quite the scene.
>> Habe Mühe mit dem Runterladen - sagt mir immer "this is not the page you
>> are looking for. Und wenn ich das Teil direkt runterlade, dann ist es
>> nur 21 K gross. Stimmt was nicht mit Github?
>> Beste Grüsse
>> Mischa
>> 2012/8/27 Stefan Hechenberger <ste...@nortd.com <mailto:ste...@nortd.com
>> We are moving quickly. Here is another release candidate. Please
>> test! I feel pretty confident about this one because we had the time
>> to run it quite extensively. I finally got USB working in VirtualBox
>> and was able to test on Windows and Linux in addition to OSX. We
>> also tested on the Beaglebone. All platforms ran the gantry
>> flawlessly so far.
>> - better optimizations in gcode generation
>> - bugfixes in com port auto-configuration on windows and linux
>> I can talk more about the new serial communication code. The details
>> are actually quite interesting. Since the serial interrupts fire so
>> frequently the slightest concurrency flaws can cause quite the scene.
> Running air assist continuously is fine. It just means that the
> compressor will run more. Also if you use nitrogen assist you will find
> yourself turning the gas on and off a lot.
> On 9/11/12 7:22 AM, Erik Moon wrote:
>> Sorry - recently started a build, so I might have missed this if
>> discussed earlier.
>> Is there a reason to not run air assist continuously while running a
>> cut / etch job?
>> -- -- -- -- --- -- -- -- --
>> Erik Moon
>> On Sep 11, 2012, at 1:12, Luke Weston <reindeerfloti...@gmail.com> wrote:
>>> On Sat, Sep 8, 2012 at 2:57 AM, Stefan Hechenberger
>>> <ste...@nortd.com> wrote:
>>>> From top to bottom the pins are even if the labels may say
>>>> something else:
>>>> A5, A4, 3.3V, GND
>>>> Also be careful when controlling the valve solenoid. They tend to
>>>> have a
>>>> pretty strong inductive kickback (30-300V). And also make sure you
>>>> don't use
>>>> any relays that draw more than the atmega328 approved 40mA. Feel
>>>> free to
>>>> start a new thread about this circuitry. I have recently shopped
>>>> around for
>>>> components regarding this and can brain dump if you want.
>>> You would need to drive the solenoid valves using a MOSFET (or BJT),
>>> not directly from the AVR.
>>> You could use a small MOSFET/BJT to switch a relay coil which then
>>> switches the solenoid valve, but assuming that the solenoid valves run
>>> from the 24V DC rail (not 120VAC) personally I would switch them
>>> directly from the microcontroller using an appropriately rated power
>>> FET. Personally I dislike the use of electromechanical, low-tech,
>>> noisy, moving relays when solid-state silicon can easily and cheaply
>>> do the same job without a relay. And, yes, you'll want a
>>> reverse-biased diode across the coil (either in the solenoid valve or
>>> in the relay) as usual to protect the transistor.
>>> You would, presumably, need a small extra PCB connected to the A4/A5
>>> assist gas solenoid header on the board which controls those
>>> solenoids.
> Craig, I don't really have a good answer to make v12.08f work for you.
> One way would be to just wait and see if anybody else runs into similar
> problems.
> I still think there is a small chance it's a line noise issue. The
> v12.08f firmware has a slightly changed acceleration profile. It's
> possible that this is enough to cause some issues if you were just under
> the threshold before. One way to find out very quickly is to jumper the
> sensor inputs.
>> I found 12.06d on git hub and all is well now. Jamie re-flashed the grbl
>> this morning from his mac.
>> The 'limit hit' error was occurring every time the machine attempted to
>> move. It would move 3 inches or less, stop, and give the error.
>> bear in mind that at no point prior to this have we had any limit or
>> door switch issues so we are pretty darned sure it is not line noise
>> issue.
>> A heads up: For the binaries we had some problems in the flashing
>> routine on windows. At this point I forgot at what point we have
>> fixed this.
>> On Thu, Sep 6, 2012 at 4:15 PM, jet <allartbu...@gmail.com
>> <mailto:allartbu...@gmail.com>
>> <mailto:allartbu...@gmail.com <mailto:allartbu...@gmail.com>>__>
>> wrote:
>> Previously they weren't getting enough power to turn
>> properly. I
>> read the Gecko and Lin manuals and changed the resistors to
>> increase
>> the amount of amps available.
>> In prior releases I could easily run the table without
>> anything
>> locking up and geting the "power off" messages.
>> I'll try and do some printf debugging and figure out
>> exactly what's
>> going on. It looks like the rest of 2012 is "debug stepper
>> controllers tasks". :-)
>> On 2012-09-06 18:38, David Armstrong wrote:
>> i’d guess a possible problem your having is the stepper
>> drivers are
>> switching off perhaps , due to drawing too much current
>> , and
>> therefore
>> they are shutting down
>> once the temp reduces then they will reset ...
>> have you checked your current draw ? , it’s normal for
>> steppers
>> to get
>> hot , and surprisingly they are designed to handle it ,
>> but not
>> to the
>> point of being able to cook eggs ...
>> remember steppers actualy draw more current when
>> stationary than
>> when
>> moving , so if they are idle for a long period they
>> can get
>> pretty hot .
>> most drivers can handle this by going into a semi
>> operational
>> state to
>> save power ... depends on what stepper drivers you are
>> using
>> so if this is happening it can result in intermittent
>> operations .
>> if the motors are becoming hot very quickly from cold
>> then i’d
>> suspect
>> you are driving them to hard , so reduce current draw
>> and perhaps
>> voltage too
>> running at too high microstepping can also result in
>> similar
>> results but
>> for different reasons .
>> or you have a some noisy wiring picking up rubbish
>> which is
>> crashing the
>> system
>> *From:* jet townsend <mailto:allartbu...@gmail.com
>> <mailto:allartbu...@gmail.com>
>> <mailto:allartbu...@gmail.com
>> <mailto:allartbu...@gmail.com>>__>
>> *Sent:* Thursday, September 06, 2012 11:15 PM
>> *To:* lasersaur@googlegroups.com
>> <mailto:lasersaur@googlegroups.com>
>> <mailto:lasersaur@__googlegroups.com
>> <mailto:lasersaur@googlegroups.com>>
>> <mailto:lasersaur@
>> <mailto:lasersaur@>__googlegrou__ps.com <http://googlegroups.com>
>> Hm, there's a problem that I thought was speed
>> related but
>> happens on
>> all speeds. The head gets to roughly X100 Y100 then
>> everything
>> stops
>> and I get a power Off message. If I'm on high speed it
>> just happens
>> more quickly, but it looks to be in the same place.
>> At the same time, all of the switches are clear but the
>> steppers are
>> almost too hot to touch.
>> On Sun, Aug 26, 2012 at 8:31 PM, Stefan Hechenberger
>> <ste...@nortd.com <mailto:ste...@nortd.com>
>> <mailto:ste...@nortd.com <mailto:ste...@nortd.com>>
>> <mailto:ste...@nortd.com <mailto:ste...@nortd.com>
>> <mailto:ste...@nortd.com <mailto:ste...@nortd.com>>>> wrote:
>> We are moving quickly. Here is another release
>> candidate.
>> Please
>> test! I feel pretty confident about this one
>> because we had
>> the time
>> to run it quite extensively. I finally got USB
>> working in
>> VirtualBox
>> and was able to test on Windows and Linux in
>> addition to
>> OSX. We
>> also tested on the Beaglebone. All platforms ran
>> the gantry
>> flawlessly so far.
We have both axes moving now and most of the chassis build is complete. We also found some zip-ties that have screw eyes on the ends -- they are a very convenient way to clean up the water hoses and the cable bundles. I think it is a much better approach than hot glue...
We noticed that the wiring diagram does not appear to be correct for both stepper motors and the left / right X-axis limit switches appear to be reversed.
When I get a chance to write it up, I'll explain what I had to do to the stepper wiring.
We should have "first light" in the next few days. Will post more updates and videos…
We were able to cut 1/4" MDF and 4 mm Acrylic sheet on our first day. It is looking pretty good.
I can't tell you how frustrating laser alignment was to complete… I think there is a serious need for some documentation on the best procedure for doing that. We stumbled onto a good solution, but I'm pretty sure we did not take the easy way to getting that done.
Did you see the manual page about alignment? It's normal to take a bit of time but should not be terribly hard. It usually takes me about 20min the first time.
> We were able to cut 1/4" MDF and 4 mm Acrylic sheet on our first day. It
> is looking pretty good.
> I can't tell you how frustrating laser alignment was to complete I
> think there is a serious need for some documentation on the best
> procedure for doing that. We stumbled onto a good solution, but I'm
> pretty sure we did not take the easy way to getting that done.
One of my (all-too-many) pet hates is websites that don't have favicons.
I've attached a couple of suitable candidates - a black lasersaurus on the
bright yellow background...if they are OK, all someone needs to do is to
dump them into the top level directory of the lasersaur website and
everything will magically work.
I just made a multi-resolution favicon in gimp (needed one for all of nortd labs not just lasersaur).
BTW: Replying will cause your message to be posted in the same thread in most email clients and on the web interface. Only sending a new mail to lasersaur@googlegroups.com will reliably start a new thread.
> One of my (all-too-many) pet hates is websites that don't have favicons.
> I've attached a couple of suitable candidates - a black lasersaurus on the
> bright yellow background...if they are OK, all someone needs to do is to
> dump them into the top level directory of the lasersaur website and
> everything will magically work.
