Teacup Firmware replicatorG & Skeinforge

check out the input-float branch too, it sacrifices code size for a significantly simpler parser

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I'll get there I promise! :-)
in the mean time can any explain how this works?
#undef DEFINE_TEMP_SENSOR
#define DEFINE_TEMP_SENSOR(name, type, pin) { (type), (pin), (HEATER_ ## name) },
static const temp_sensor_definition_t temp_sensors[NUM_TEMP_SENSORS] =
{
#include "config.h"
};
#undef DEFINE_TEMP_SENSOR

if you undef something then you are assured you can use it with #define.
so why #define something then immediately #undef it?

oooooh! joy!
I just noticed that eclipse C/C++ recognizes which branch of git I'm in! sweet! maybe there is a git plug-in..
item 1043 on my list of things to do!.

Architect Wrote:
-------------------------------------------------------
> I'll get there I promise! :-)
> in the mean time can any explain how this works?
> #undef DEFINE_TEMP_SENSOR
> #define DEFINE_TEMP_SENSOR(name, type, pin) {
> (type), (pin), (HEATER_ ## name) },
> static const temp_sensor_definition_t temp_sensors
> =
> {
> #include "config.h"
> };
> #undef DEFINE_TEMP_SENSOR
>
> if you undef something then you are assured you
> can use it with #define.
> so why #define something then immediately #undef
> it?

Ah, this is some brilliant magic contributed by stephen walter (sw). Basically we're redefining macros and including config.h multiple times so one line in said config can fill in multiple data structures. Still a few issues, but it's a fun and interesting abuse of the preprocessor. So far we're filling in an enum and a struct then cross-linking into another struct

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

That scares me....
I knew there was a reason I took this project on. one learns a lot by throwing oneself off a cliff. :-) hope theres water down there...

triffid I'm just gonna accept that as "cool Sh*t to dig deeper into (someday)" I'm having a hard enough time keeping track of pointers and the like. I'm a Oracle developer and Java guy circling back around to get some OG programing skilz yo!

update, Almost done merging code with the master, keeping things like DC motor out of my branch as well as the Gen 3 stuff.

the question hit me yesterday, Why use Gen 3 hardware and the 2 atmegas with this project? I kinda feel that there is a lot of feature creep and distractions from the core firmware. I take that to be receive, process and control. I think everything else should be plug-ins seperate from the gcode processor, dda and timers.

just my 50cent or perhaps a developing ideology.

-Karl

Architect, the #undef is there primarily to prevent the compiler from spitting a warning at us. If you #define something, and later #define it differently, the compiler will warn you about that - primarily because it's very seldom done, and it can lead to very hard-to-find bugs. If, on the other hand, you really *want* to redefine something, you can use #undef first to avoid the warning.

So that's what's going on there - we're redefining DEFINE_TEMP_SENSOR to do something a little different with it's arguments the next time around. In this case, we're using it to initialize that constant array of structs with data about each temperature sensor. If you look in config.h, it's defined as DEFINE_TEMP_SENSOR(...) if it's not already defined. Which basically means to remove it and it's arguments from the code completely. So, *normally* if you include config.h, those lines are removed. Here we include config.h, and those lines do something.

---

--
I'm building it with Baling Wire

Architect Wrote:
-------------------------------------------------------
> That scares me....
> I knew there was a reason I took this project on.
> one learns a lot by throwing oneself off a cliff.
> :-) hope theres water down there...

do some assembly. C makes tons more sense once you've done a bunch of assembly. Trust me, that's the only way I could learn it myself.

> triffid I'm just gonna accept that as "cool Sh*t
> to dig deeper into (someday)" I'm having a hard
> enough time keeping track of pointers and the
> like. I'm a Oracle developer and Java guy circling
> back around to get some OG programing skilz yo!

ah, your first real programming language, welcome to the next level

> update, Almost done merging code with the master,
> keeping things like DC motor out of my branch as
> well as the Gen 3 stuff.

master has dc motor and gen3 stuff already, just fyi

> the question hit me yesterday, Why use Gen 3
> hardware and the 2 atmegas with this project? I
> kinda feel that there is a lot of feature creep
> and distractions from the core firmware. I take
> that to be receive, process and control. I think
> everything else should be plug-ins seperate from
> the gcode processor, dda and timers.

no need, but we support them because that's what many people have who would like to try this firmware. We have a design goal that this will work on as wide a possible range of electronics configurations. Originally we didn't even support gen3, but jakepoz kindly provided the initial support which we've recently upgraded significantly with markus' help.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

well, Somewhat productive day today.
rebuilt my Heater Controller module. much smaller design just a bit bigger then the polulo stepper driver. it controls the thermistor, extruder heater and has output for a fan (if ever necessary) . pict attached.
plus got the thermistor and heater to work with the latest master code which I am trying to merge into the branch I have been working on for awhile. After some modifications I am using BANG BANG right now. the fluctuations at temp are too big a swing for my liking with BANG BANG so I will work to get the PID and PWM working later.
BTW, BANGBANG I think had a bug in it where it was turning on when off and on when it should be off.
I found the issue in the Heater.c file. here is the change I made.
~line 180:
if (current_temp >= target_temp)
pid_output = BANG_BANG_OFF; // was set ot ON
else
pid_output = BANG_BANG_ON; //was set to OFF

my temp table differs from the standard so I keep it in the .c file for now but I like the Idea of putting it in a separate file as that seems to be the current way. I might want to put the PID defaults in there too.

X,Y,Z axis all seem to be functioning correctly with the current master code, I need to look at the changes for the Extruder to see if it is actually stopping while in travel. plus I think I need to revisit my Z axis calibration when i did the number earlier It seems It should be off at the current 2999 steps_PER_mm.
after that (or maybe before) I will do more large file printing. and the latest version of replicatorG has a noise variable for testing the resend function. I want to utilize that to really hammer the Checksum functions with the resend and DDA queue work I had. need to make sure its still working with the merged code.

yeah I've been playing with the checksum/line number resend stuff, seems good from my end but the whole parser could certainly do with some thorough fuzzing, particularly the input-float branch which holds a new parser implementation I've been pondering for a while

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Well, more progress. Fixed my min end stops. When open they report high when tripped they go low. This seems at odds from
The general public as the merged code which has the endstops implemented handles it differently. If anyone needs the change I can
Post it. The min. Federate does not seem to be working. Skienforge added a F100 to my z axis for homing and I have my min set to 200
As that is the slowest I can run my stepper. It didn't like the 100. After that though I was able to get a good print with~56k commands. It took
1.45 hrs but hey, it finished cleanly. Seems to handle switching between absolute and relative too.
Unfortunately I didn't have Diminsions turned on so it did not generate E codes.
First time I noticed this in my test file because I was wondering why the extruder stepper wasn't running this time.
Triffid, hope this is cuz of the new E handling. Which suggests it's working. Regenerating Gcode now with raft , temps and E codes.
Crossing my fingers. I also Rewired my reprap. Added stronger connectors to my steppers and found use for my leftover compmod wire
Wrappers. Pict to follow. It's getting close to the time where I need to design my circuit board. :-) my breadboard is getting crowded.

if the gcode says F100 and the min is 200, it should run at 200 regardless. haven't tested it myself though.

pinio.h lists X_INVERT_MIN and friends, perhaps add them to your config and tell me if they work as intended

This firmware has never run the extruder on M101/M103 except for oozebane-style stuff.. the DC extruder stuff is a recent addition, so gcodes without E-words would never have run the extruder more than a few steps in either direction

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Teacup? Really... Oh man. Lol

Its all Good! just hold the milk and sugar!

So turns out yesterday's progress was actually 2 steps back.
My rewiring of the steppers and endstops caused a lot of noise on then endstop lines. I really got what was discussed awhile ago about false positives with the endstops.
My misttake I believe was using cat 5 cable to carry both the stepper lines and the endstops. Prior I had the endstops along the outside of the cat 5 which of purse is shielded. The results were when testing each layer was off by ~10 mm in the x positive direction.
Well fixed all that Nd tonight I was able to get pwm temps with PiD working again. Problem is in ReplicatorG I have no way to send
Lines of Gcode. So setting the M130-M133 commands are not easy. Plus with the current version of repG on my unbutu box I can only send one print then I have to restart the program. So for now I need to use repsnapper to test temp control and redo pid tuning. It's good up to 200c but I pushed it too 220c and it had a hard time getting and staying there. Triffid, do you send M130 commands in your Gcode or do you save to EEPROM every print? How is thatsuppose to work anyways?
When should one save to memory in Gcode?
Or is that something I haven't found in the interupts or somewhere else?
Anyways enough for now.
Thanks for listening

do your pid tuning with a serial terminal, ./func.sh mendel_talk is a simple one that will work on your linux box, alternately screen can be used as a serial terminal as can cutecom, minicom, etc. not sure of windows offerings, just know that hyperterm is horrific and a major cause of errors unto itself. It's easier with DEBUG enabled, turn on PID debugging with M111 S1 (see debug.h for S-values) which will show you the PID values and factors as they're calculated so you can see how much influence each is having.

When you have found PID settings that you like, save them to eeprom (M134) and they'll be restored every time the firmware starts up so you never need to send them again

Alternatively, stick them in your startup/homing file.. all the slicers have one somewhere, I think repG's one is in machines.xml

ps: cat5 is usually not shielded, but the twisted pairs eliminate quite a lot of noise by cancelling radiated fields if you use the pairs properly

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

A great windows serial terminal is Realterm - and can be used to send files to the device as well
http://realterm.sourceforge.net/

Thanks all for the serial term suggestions but I run this project either off my mac or my Unbuto( I try to avoid my PC whenever possible) box so no need for a term other then what I have handy. Triffid, the stuff in func.sh is great use it all the time.
So, been on Vacation this last week. sitting out in the sun in San Diego, Ca. doing nothing but drinking beer and tinkering.
I brought along an LCD I got with my MEGA from china. only $50 for the bundle so what the heck. also brought along my 328 (which has 3 dead pins) after some screwing around with the pins was able to get the LCD working as expected. thus I ordered a new NANO to control it and wired that up. next I used the I2C pins to control the NANO/LCD from the 328. This worked great and I designed a temp screen with rolling graph to monitor temps (picts attached) the NANO gets its 5v power off the 328 as well as communications from the 328. So... when I get home to my machine I'll need to incorporate the I2C master code into my TeaCup firmware. the game plan is to send temp readings to it over the I2c. I also picked up a thumb joystick to attach to the LCD this might be useful for changing displays on the LCD as well as possibly sending Gcode directly to the MEGA via the I2C wire. might be fun. next screen will be the output of POS.
So, here is my Question(s).
Has anyone incorporated I2C with teacup yet? if not, where might be the best place to put in the send commands over I2C? I'm planning on sending over all the relevant data as binary and decoding it on the NANO. I need to think about getting the control data back from the NANO as well as disabling the joystick during a print. all this doesn't sound to difficult.
Hope everyone's having as good a week as I am.
thanks for listening.
Trout

Hi, the intercom protocol is similar enough that you could take many pages from its book

clock.c has all the periodicals, I'd start there

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Just found this thread.

Probably better moving over here of r working between Teacup and Replicatorg24.

Just working through some random problems, not sure where they are yet. What have you been using for tracing your serial comms between ReplicatorG and Teacup Architect ??

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Nothing really just tail the ReplicatorG.log when I want to track down the debug stuff. Use the func.sh scripts when I need to push single Gcode commands and the like.
I think I'm still using repG22 on my Linux box and 24 on my Mac laptop. Just back off of vacation so I'll be working on this some more.

well, some progress, cleared some noise coming from my heater board on the PWM pin and hooked up my LCD.
now I have real time graphing of my temps. making it much more interesting for tuning. heres a pict of the LCD hooked up. my PCB supplies will be here next week so i can gain back some of my breadboards.

lovely, what code are you using to drive that?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I found the TWI application notes and basic driver code on Atmels site here AVR315
I modified it a tad to compile. and for now I just send the temp variable div 4 to the slave this then was written in cpp to display the temp graphs and such. for now I am sending the temps during the heater_tick call on every 100 calls(?) about one every second. I had to enable the PRTWI in mendel.c but after fighting with the proper way to address the slave(grr) it seems to be working great. I can now give my DMM thermistor a much needed break. BTW, know anything about thermistor at high temps? I got my system tuned at 150C but my thermistor seems to like to stay at 220C and wont read anything more higher. I've pushed my heater to 240+ but for some reason my raw ADC starts to fall off at ~220. anyways working on that now. working theory is the higher temp is effecting the resistance of the thermistor. trying to prove out that theory somehow...

maybe your ADC runs out of precision around there? does your thermistor table go above 220? Some thermistors are only rated to 150c or so, you need one rated to 300c. What's a typical raw ADC reading at 220c and above with your thermistor?

the TWI stuff sounds interesting, are you generating the graphics on your motherboard, or does it have a slave chip in it or something like that?

ps: run your code from clock.c rather than hooking into heater_tick. there's already a CLOCK_FLAG_1S waiting for you

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

all the graphics are generated on the slave board. I picked up a NANO328 (tiny little thing) for $30.00 and used the Arduino glcd and "Wire" Libraries which were pretty easy to hack together. cool next on the todo list is integrate this thumb joystick module into it and have gcode sent back to my main board. I'll definitely want to put this into clock when I clean it up and add the current dda position information. that'll be on a different selectable screen by the joystick.
as for the Thermistor I think your right. its hardware. my tables resolve upwards to adc975 accurately based on the Steinhart–Hart formula. but the raw adc reported tops out at 924. I have a Thermocoupler inside my barrel telling me its at 240C. I bought my thermistor from makergear.com figuring it was rated correctly. reading the datasheets (Again) on it. which do state nominal resistance up to 300.... ah well It'll get solved. if anyone out there is reading this as well heres some hardware setup if you see anything wrong let me know.

I'm wired up as : 5v -> 100K thermistor -> | Temp signal | ->4.7k R -> ground

I get very accurate readings up to ~190C then it starts falling behind my DMM temp readings and will not read past ~220 with a resistance of 473Ohms (my resistance drops as my temps increase)
danka

well, I think I figured it out but its too late tonight to do anything but sleep.
after that last write up I took a look at my heater/thermistor diagram and then decided to check all the values coming in and going out as well as all the resistor values. everything looked good until I checked the incoming voltage... still didn't register as to what the problem might be. (I thought I could fix it in the temp table somehow) anyways, after a beer it dawned on me! my incoming voltage to my thermistor is already hobbled! i read 4.59 volts not 5v after doing some math rechecking everything it turns out that@ 4.9mV per unit on my thermistor the most it will ever produce will be 929. so Its not software. So I know this is the firmware forum, and I put a lot of hardware issues in here but they are connected so... :-) one more beer.
maybe if I just add a multiplier to the table values like 5/4.59.... sleep

Ok

Problems I am getting with RepG24. (Ramps board and build)

I got it to connect ok by tweaking the setting in machines.xml. I started with the RAMPS profile under arduino.

Needed to extend the timeout as RepG timed out before the Start came from the firmware.

So they initialize ok and I get the green banner to confirm in RepG.

Heading towards the manual move screen I get random weirdness.

Moves sometimes work sometimes not. Homing doesn't.

The moves can often lockup one end or the other. When moving the Machinery seems to be getting regular resets or some such. The motors not involved in the move are twitching like they do when the board is reset. Bout every couple of seconds during the move.

When the move hasn't happened and RepG is unresponsive if I look at the rx/tx lights on the arduino they are pulsing like something is being sent one way or the other at regular intervals.

When the move has halted or isn't happening and RepG is responsive sometimes a machine stop will get it going again.

Trying to do a second move (even a further increment of the same axis) whilst one is already in operation leads to it locking up. This is fairly repeatable but sometimes works ok.

All in all it has the feel of a protocol mismatch on the comms.

Attempts to get socat to do a full trace of what is happening with the comms is'nt. RepG does'nt seem to want to accept that the socat PTY port is a serial port that it can use. It gives error in serial window saying device is'nt a serial device, so no trace available as yet.

That is about where I am at the moment.

Next stop is use the scripts to talk to the machinery see if it is any better.

Not got to heating and extruding yet, will take a look at these once movement and homing is sorted.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Few questions,
What baud rate are you communicating at@ I found The best setting was at 56700
Do you have endstops enabled? There were lots of issues with noise on that issue.
Turn off required line numbering and checksums in the firmware until you are ready to tackle that one.
All serial communications are logged in the ReplicatorG.log file. Including and responses from the firmware.
This log file is usually located in the same location as the app.
What platform are you running RepG?

another thought,
did you adjust the driver boards for your steppers? turn the pots fully right I think then back them off a 1/4 turn to start with.
they may not be getting enough juice to handle the signals.