Weird problems controlling d57 on ramps 1.4?

ok so here is what i am having an issue with..I programmed pin d57 to turn off the torch height controller and turn it back on ..I set m95 to turn it on and m96 to turn it off..I am using a low active relay..So m95 turns pin d57 to 0 and m96 turns pin d57 to 255.. This works great when just manually typing the m95 or m96 into repetier.. And it works great for the first minute or soo when actually running a code but after roughly a minute the thc will not turn back on like it should..The gcode looks good but it is not changing the status of pin d57 when it messes up...After it starts to mess up it will work real irratic. My guess it is causing a fuse to overheat and that is why it stops getting 5 volts when it should..My machines have an lcd screen hooked to them which i know is suppose to put the 5 volt side of things on the edge just by itself..When it messes up the lcd screen will (blink) off for just a split second ..Is there any way to test to see if that is why the d57 pin stops putting out 5 volts when it should?I have tried it with three different boards and they all mess up the same .Here is the piece of code i wrote to make it control pin d57 with the m95-m96 code.I also added the pin definition in the pins h for it as well

.

Just a shot in the dark, but why use analog commands on a digital pin?? Shouldn't you switch the pin with digitalWrite(57, HIGH); and digitalWrite(57, LOW); ?

---

-David

Find me online at:
Thingiverse
Instructables.com
LinkedIn
Facebook

Check out my FolgerTech Prusa i3 (plexi) at MindRealm.net

I tried doing it as a digitalwrite high and digitalwrite low..for some reason it didnt work..i will spend some more time working with it ?for now i just ended up putting it on the d8 and changed the time between temp chaecks to 50msand put a thermistor on it to fool it into thinking i am running a heated bed and it works nice..but i wanna go the other way with it but for now i have things things i need to finish testing..

ok so i decided to just turn the thc off and on with the d8 using the m140 s150 and m140 s0 just like it would be if i had a heated bed hooked up i put a 100k thermistor that is reading between 26 and 30 depending on the shop temps? i do not have the watchdogs enabled in the firmware and i set the bed check interval to 100 instead of 5000 .. and it is acting up just like ti did when i was controlling it on the d57 with the m95 and m96 like i did earlier..now it is on sometimes when it should be off then off sometimes when it should be on..All the motors keep woring perfect and the torch off and on works fine which is on the d9 being controlled by the m106 and m107..I am really at a loss for ideas here any imput would be a big help .. it does it on three different controllers .tried two different usb cables and two different computers.. all do the same thing

How much current is being drawn by the relay? Do you have a bypass diode across the relay coils? For safety of the digital electronics, it would be a good idea to drive the relay with a small mosfet instead of directly by the processor pin.

Even running it on the d8 which goes runs a mosfet it does the same thing..The more i think about it the more i am thinking somehow my marlin file must be corrupt?Why does it do the same thing on the d8 as it does on the d57 since they are being controlled totally differently. The d57 is a simple off-on while the d8 is being used as if it were a heated bed with only one change to the stuff that controls it...I only changed the check head bed interval to 100ms from 5000ms..So i am looking at what change is common wih both ?Althought it still doesnt make sense to me why the torch off-on that is on the d9 and all the motors work fine when it is messing up????The only thing malfuntioning is the thc off and on And it doesn't matter which pin i put it on and how it is being controlled??Seems this is the straw that broke the horses back .It acts as though there is another program running in the background running anything added recently sinnce they turn on at times when they should be off and off at times when they should be on..And during other parts it works fine..I think i need to download and install the latest version of marlin and start over?Does anyone have the link for it?

I downloaded and installed the latest marlin firmware and it still doing the same thing the d8-heat bed is acting crazy it is on when it should be off and off when it should be on and sometimes it is right.. it is doing the same thing it did with the previous firmware ..It messes up in exactly the same way in the same places..Maybe the issue is in repetier host??Maybe it is not sending what it is saying it is sending?

This is the relay i am running when using the d57 pin..it has leds for the vcc and in and other resistors..I would think when running this type of relay you would not need any other diodes or resistors?[www.ebay.com]

I am beginning to think the problem lies in repetier host.i downloaded the latest marlin firmware and latest arduino ide and it is still doing the same thing i even changed the case for the m106 and m107 to the m95 and m96 and it did the same thing..this is really interesting as the m106 and m107 worked fine before with how the relay and wiring were done.i just changed which g code runs the same command and then it stops working?I did the same using m140 s50 and m140 s0 in place of the m106 and m107 ....Same results.so this is telling me it is either something with the code not being sent right from repetier host or something to do with how the g code is being read by the firmware..which i think it is more likely a bug in repetier as it has the ability to disable the heat bed and might not send the m95 and m96. When it is in the gcode.i ran a file and manually typed in the m95 and m96 the ones i manually typed in worked fine the ones in the gcode did not. ..since it is always happening in the same place it almost seems like the m140 s50,m140 s0,m95,and m96 are not being run in the order they are writen in the gcode.but instead being kicked to the end of the 20 line buffer and being run then...

I have been really working to try to get this issue fixed..This is what i know so far..First the problem lies in the firmware.I put the files that were messing up on a sd card and they did the same thing as running from repetier host .So this eliminates it being a problem with how repetier is sending the g code..Second it is not a problem with the g code or post processor..I do know it is a problem with the M codes not being buffered..Which is really confusing as a m106 and m107 work just fine..I tried to control it using analogwrite ,digitalwrite,or running it like a fan with speed control ,and as a heater with a thermistor ..All had the same results

After this i decided to start to break down and eliminate things in the g code that could cause it and try different things to make it work?I deleted all the m106 and m107 commands and ran it.....Same thing..I deleted all the moves and just ran the m95 and m96 they ran but so fast you could barely see them switching ..SO i decided to add a pause after it does the m95 and then after it does the m96 this way i could see the relay change state..This worked the relay consistantly changed state as it should.. then i added the moves and m106-m107 commands ... it went back to not working..After this i added pause before and after the m95 and m96 this worked..

With this i know i can fool the firmware into putting the m95 and m96 into the buffer..however this is not a feasible fix as you can not stop the torch travel mid cut without effecting the cut quality.. SO this is where i am now i need to find in marlin where you set which commands are buffered or set the parameters for the buffer..I have looked all thru marlin and can't seem to find this.I have found where you could set the plan buffer for different things not sure if this is what i would need to change or if the stuff for the buffer is in one of the libruaries?It seems there must be a list of commands that are buffered and i would need to add the m95-m96 to this list..Any help understand or accessing the buffers would be greatly helpful at this point.