Running Teacup standalone

[Traumflug]

From a PM on reprap.org:

Thank you for all your insights on the experimental thread, I have taken your advice and have gone with Teacup and got everything working really well. Since your an expert in Teacup I wanted to ask if you knew a simple way to run the gcode straight off of the arduino somehow using the teacup firmware, and bypassing the need for a serial terminal. I was hoping to have this project be capable of storing the routine and the firmware on the arduino so that a computer would not be required but am worried that may not be possible since I cant upload teacup, close arduino app on computer, and then send the commands to the motors. Arduino app has to be open for it to work, right? Do you think what I want is possible? Or should I try and change strategy while I still have a little time?

Thank you for all of your help, I know that if you dont think this can be done to be plug and play that I should stop wasting time and look for another method.

[Traumflug]

(that's me now)

You're right, RepRap firmwares aren't really suited to run without host. Some run G-code off an SD card, but then it's one-off, too, not repetitive. You'd have to start each repitition manually.

Arduino IDE isn't neccessary at all, but an application to connect to the serial line, sending commands. An RaspberryPi would serve this task well.

• How many lines of G-code are we talking about? Would that fit into your controller's flash, in addition to Teacup it's self?
• Is some initialisation code, like searching endstops, necessary?
• Is additional interaction over the serial line still neccessary? It might become tricky to decide wether to follow commands from flash or commands coming in over the serial line.

[colinpoly]

I would first like to thank you but also want to say that I put a lot of value on your help right now because I am getting close to my due date for this job. So if my questions become too much or too numerous or you feel you have spent more time than you would like helping me, I have no problem sending you some payment because as far as I am concerned your providing expertise and I have room in the budget for that if your willing to help me get this finished.

That being said here's some answers to your questions.

I have a raspberry pi on hand so that would be easy to try out on my end.

My slightly modified Teacup Firmware takes up 17K, the file I have been testing with (20 lines), in text format, is probably about 5% of overall code size and takes up 215 bytes. Each line of code calls on 1-4 motors and so far I have been using a constant speed defined in the config.h file, overall it will probably be between 200-400 lines. By my math I think that should be more than fine for the remaining 15K on flash. I have speed pretty slow and I would like to get it to run for 10 minutes without repeating but would be happy with 5 minutes if 10 takes up too much space.

I will attach some pictures so you can see the hardware I am working with but no there are no endstops or initialization required, the platforms I need to spin can spin indefinitely and they have no start or end point that must be taken into consideration.

Everything seems to be much simpler than actually operating a 3d printer and the only issue is trying to make it do things a 3d printer doesnt normally have to do. I would love to make it so that I would be confident that all the artist has to do is plug in a surge protector and flip it on to make it start with interaction on his part being zero to none. So if it can follow a list of commands, repeat them, and store all of this so that it can be turned on and off with 1 switch, that would be the ultimate goal. There will be no need to mess with it after it can do that so however its done it really does not need any extra capacity or room for modification.

The motor will turn each ring via timing belt (not shown). Let me know if theres anything your not clear on and Ill respond as quickly as I can and Thanks again, really appreciate all the help.

Colin

[triffid]

I think it would be a fairly trivial modification to stuff your movement sequence into a string, then repeatedly inject it into the gcode parser from main loop - if you're handy with writing C that is!

you'd basically need to detect when the queue has room, grab the next line, and feed it to the parser

having support for this folded into upstream is fairly unlikely, you'd probably have to keep your own branch in a fork of teacup.

I'd strongly suggest having the gcode as a plain file, and get the Makefile to generate suitable inclusions for you. That way, updating the canned sequence is as trivial as editing a raw file, then doing make/upload

[colinpoly]

triffid would you like to make a couple hundred bucks? I am not handy at writing C and really comprehending comment would probably take a couple of hours if I am lucky.

[Traumflug]

the file I have been testing with (20 lines), in text format, is probably about 5% of overall code size and takes up 215 bytes.

That's easily doable. I was asking because multi-megabyte files are not unusual at RepRap. Some code cruises through my brain, I'll spill that out later today.

[colinpoly]

Awesome I appreciate that, just so Im not confused am I going to need to incorporate the rPi? Im setting it up with raspbian but will stop messing around with it if you think there is another way.

[triffid]

https://github.com/triffid/Teacup_Firmware/commit/a950533616d2f41b65414ae32e5523bac87ac693 should get you started.. completely untested (I don't have hardware handy at the moment) but it compiles at least.

you'll need to add #define CANNED_CYCLE to your config.h

[Traumflug]

I guess it'll be AUTOEXEC_STARTUP and AUTOEXEC_LOOP in config.h. You put the commands in there, compile, upload and it'll run without any communications. That's what I think you're asking for. The only way to stop it will be to pull the power plug or hold down the reset button permanently, then.

When going the rPi route you have more control, of course. You can turn on XONXOFF in config.h, then just send G-code to the serial line. Like

cat my.gcode > /dev/USB0

No need for custom software and that's doable right now. Still writing scripts for more spiffy things is possible, of course.

[Traumflug]

triffid@a950533 should get you started..

Ha, you've beaten me :-) That's pretty exactly what I had in mind.

[colinpoly]

I need very little control, like I said I want this thing to be set up and then just crank out the movements reliably, and what you described in the first paragraph sounds exactly what I need. Okay I will try that and report back with any issues. Thanks guys!

[colinpoly]

Where do I add in AUTOEXEC_STARTUP and AUTOEXEC_LOOP or I guess how is a better question. And when I added #define CANNED_CYCLE into config.h it shows me this:

[triffid]

eh, didn't say that here.. no idea what it's on about; that isn't a local variable.

I didn't try in arduino IDE though, I use the Makefile. maybe try removing PROGMEM from the header? oh, you'll probably have to generate canned_gcode.c by hand if you're not using make, it looks like this:

#include "canned_gcode.h"

const char canned_gcode[] PROGMEM = "G1 X100\nG1 X0\n";

and my additions to Makefile-common autogenerate it from canned_gcode.g

[triffid]

oh also I didn't see any AUTOEXEC stuff in master branch, that's why I added things in for it

[colinpoly]

Ahh of course I forgot makefile is alternative for using ide, correct?

[Traumflug]

Fine. Picked Triffid's commit up, fixed two bugs and pushed all this right to the experimental branch.

Another two commits move this new stuff from a dedicated file right into config.h. While it's a bit more work to put commands in there (you have to add " and ), I hope it's easier to understand for Arduino users. Should compile with Arduino IDE.

If you get an error about a missing canned_gcode.h, you have to manually remove canned_gcode.c. Shouldn't happen if you start over with a fresh copy.

Short description: http://reprap.org/wiki/Teacup_Firmware#Canned_G-code

Does it work for you, too?

[Traumflug]

BTW., if you have an own config.h already and want to keep it, just copy & paste the new section from config.default.h. It's close to the bottom.

[colinpoly]

Wow! Had to step out but was getting emails and felt so guilty for leaving. Trying this all this now Thank you thank you thank you

On Sat, Aug 30, 2014 at 8:58 AM, Traumflug notifications@github.com wrote:

BTW., if you have an own config.h already and want to keep it, just copy & paste the new section from config.default.h. It's close to the bottom.

— Reply to this email directly or view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/101#issuecomment-53957772 .

[colinpoly]

Okay so I have my config file the way I want with the added section at the bottom from experimental. All of the added section stays gray, is that right? Where do I put my motor commands now? In the canned_gcode.g file?

In all I need canned_gcode.h and canned_gcode.c and canned_gcode.g (With motor movements i believe?)

Sorry I am trying to get everything (files) you both discussed together into the teacup folder, is that what I should be doing or have some files in early comments become obselete with improvements in later comments?

[Traumflug]

All of the added section stays gray, is that right?

You have to remove the comment markings ( /* and / ), of course. Then compile and run, X should move back an forth. The canned_gcode.\ files are no longer neccessary.

That running, you can start to change the G-code you just removed the comment markings from.

[colinpoly]

Incredible guys, I seriously cannot thank you both enough, my buddy came over and helped spoonfeed me your solution and he said contributed essentially nothing and that it was all already done. I am currently working on both the physical build and the couple hundred lines of motor commands but will most definitely be back to post some videos of this project, or if I hit any snags of course :)

[colinpoly]

So the physical build is wrapping up now and the gallery opens on friday so it should be completed by tomorrowish, but I had another question that maybe you guys could answer for me. I have done some preliminary searches on it but dont have the time to dive too deep so if there is a simple solution then that would be great, or if there isnt a simple solution I would be equally appreciative in order to save my own time from being wasted.

The artist wants the piece to run for approximately 8 hours at a time, which I think will probably cause the motors to get too hot. From what I have read, this can be remedied via enable/disable pins on each motor (I dont have those hooked in because I didnt appreciate their use until now). The loads are very light for the motors I have but even when they are not in use they heat up if power is on. I am using an UNO, would enable/disable pins allow me to code in a long break that can actually be used to cool off? Or am I way off the mark? Any insights into this would be great or even just letting me know if there is an easy solution for this or if I should just risk them getting hot because any solution is difficult or impossible. Thanks again.

Colin

[Traumflug]

The artist wants the piece to run for approximately 8 hours at a time

Everything past one hour should be in thermal steady state, so no additional warming.

this can be remedied via enable/disable pins on each motor

There are pins on your motor? Mine don't have pins.

The loads are very light for the motors I have but even when they are not in use they heat up if power is on.

That's expected, stepper motors warm up in standstill more than, or at least equally, when turning.

To reduce warming you have to reduce the current flowing through the motor's coils. Most stepper drivers have a trimpot allowing to adjust this current. Reducing current also means reducing torque.

Rule of thumb: turn this trimpot up just enough to make the motors move reliable in all situations, then add another 10% for a reliability margin. The other adjustment rule is: raise current as much as motor heating allows, then adjust acceleration and maximum speeds to keep them moving reliable. The former one is probably the better one for you, as reaching a maximum of acceleration doesn't matter in your case.

If there is no such trimpot you have to reduce supply voltage to reduce current.

[colinpoly]

Oops pins on my microstep drivers* No trim pot on those but they have more adjustment possibilities than I could try out so I will use your advice to see what works best. I have steppers rated at 2.8A and 200steps/rev and the drivers allow for 1.5A-4.5A (plus a half/full current switch) and go from 400-50,000 pulses/rev. I have been using 2.8A (on full) and 1600 pulses/rev for the drivers but just did that because it seems relatively quiet and pace was okay but if you think theres room to cool it down without changing sound let me know.

I guess my only real concern is that I bought this vibration dampening rubber type material to reduce overall sound/vibration and its only rated up to 125(F) degrees...I have been using it on the motors where they mount to wood. The spacing is all just right with it as of now..but Im worried it may begin to melt. Im testing it at the moment but I am still debating whether or not to scrap the rubber and use a different material as spacers that cannot melt or whether I can just limit the temp and stick with it since its already in place.

[Traumflug]

The higher the microstepping, the quieter stepper motors are. Teacup makes up to 40.000 (micro)steps per second, which limits top speed. So if you set your drivers to full 50.000 steps/rev, you can move 288 deg/second top speed. There's no reason to not move close to the max step frequency.

If you refuse to reduce current, then yes, the rubber might start smoking or melting.

[triffid]

The current rating on a stepper motor is typically the current that causes it to sit at ambient+50°C or so.

Current is approximately proportional to torque, so if your motors are producing ample torque you can safely reduce the current for a big drop in heat.

heat is proportional to square of current, so dropping current even a small amount gives a noticeable difference.

[Traumflug]

I think this is solved. Please open a new issue when something new arises.