As per your other reply. My code is your code. This is a clean clone of the current master with only makefile, config.h and the thermistor tables edited. The host is GTKterm with xon/xoff enabled. I could accept perhaps that some of the apparent random ok thing is the streams being mixed together poorly by gtkterm. I will have another testing session in a day or two, when I get time, with theby aka47 - Firmware - experimental, borrowed, and future
Actually sorry guys the past couple of posts have been heading rapidly off topic. I have cut and pasted my last to the teacup firmware thread where it is arguably a little more on topic.by aka47 - Firmware - experimental, borrowed, and future
I thought I had better move this part of a discussion from another thread where it was getting off topic to here where it is on topic. --- snip --- consider:- M105 M109 P0 S225 M105 This should in sequence do :- M105 get the current temperature of the extruder (ambient if from cold) M109 P0 S225 Heat the extruder up to 225 Deg C and return when at temp. M105 get the current temperature of thby aka47 - Firmware - experimental, borrowed, and future
I think we are missing the point a little, probably I have'nt explained it well. consider:- M105 M109 P0 S225 M105 This should in sequence do :- M105 get the current temperature of the extruder (ambient if from cold) M109 P0 S225 Heat the extruder up to 225 Deg C and return when at temp. M105 get the current temperature of the extruder (now reading 225 Degrees C) What we do get instead is:-by aka47 - Firmware - experimental, borrowed, and future
> I'm not sure why reprap host, replicatorg and repsnapper all have trouble with this, I might have found a contributor to this, posted it in the Teacup-Firmware thread of this forum last night. The host wares are sensitive to the prototocol of commands and responses. Not just the protocol of byte transfer. (gtkterm, file cat etc are only bothered about byte transfer) In Teacup some of theby aka47 - Firmware - experimental, borrowed, and future
Yup I have always been a little cautious with using logical shifts for arithmetic purposes and stuck to unsigned values. If I needed belts and braces I would logically combine a mask to forcibly set/clear the bits that have been shifted out of as apropriate. The speed benefits of using logical operators and binary increments/array sizing are so massive that I have used them many times. Particulaby aka47 - Firmware - experimental, borrowed, and future
If I had to guess what was happening I would guess that :- 1. Non buffered commands are being executed immediately they are received and are never put in the buffer. 2. The buffered commands are being put int he buffer to be execute later. 3. Because of this non buffered commands are prioritized over buffered commands and execute even though there are commands already in the buffer. This fitsby aka47 - Firmware - experimental, borrowed, and future
OK I have reduced the uStepping and the positioning looks better. I am still not getting the correct values back from the query commands, I think though it is related to the fact that the commands are not executing in sequence. Even though the G-code is in the correct sequence in the file and the machine is waiting for the head to heat up. The funny thing is that both of the what temperature ?by aka47 - Firmware - experimental, borrowed, and future
Thats quite subtle. In the past I have used a ring buffer to keep samples in and for each one subtracted the last just taken from the ring buffer from a total (the running average or oversample-total ) and then added the new one to the total before puting it in the ring buffer then copied the total and done the shift for division or decimation. A lot quicker than summing every value on every samby aka47 - Firmware - experimental, borrowed, and future
There are a few arguments in favour of using techniques like these to improve the ADC readings. 1. The time constants (or response if you like) of thermistors is very slow compared to the speed of a free running ADC & Interrupt scheme like Teacup uses. We are effectively massively oversampling any way, why not put it to good use ? 2. All RepRap machines and firmware are by virtue of being mby aka47 - Firmware - experimental, borrowed, and future
Something with a little more pictures and less reliant on math and relevant to atmel....by aka47 - Firmware - experimental, borrowed, and future
Guys The sampling thing you mentioned earlier in this section is Oversampling and Decimation. Along with some other tricks like low pass filtering (averaging to everyone else) you can do some clever things just by rearranging how you collect together your samples, without getting into the full FIR DSP thing. Is a fairly good doc that collects together a bunch of useful stuff. Cheers aka47by aka47 - Firmware - experimental, borrowed, and future
Nearly 400 times the microsteps. This is largely due to the mech being a huxley using m6 lead screws (1mm per turn) and the drive belt sprocket ratio of 8:15 ish. I think I might reduce the microstepping for the Z axis as the number of stepps is clearly overkill. It will certainly make the numbers a bit more manageable and reduce the work the fimrware has to do. In fact as I write about it I sby aka47 - Firmware - experimental, borrowed, and future
Guys Just spotted something odd with the Master branch. The delay doesn't look to be working very well (G4) and my Z axis isn't updating it's position. I have been messing with building a simple initialization block of G-code. Something I could cat onto the front of G-code objects to be printed. As it wasn't operating how I felt the G-code should operate I sprinkled in some G-code statementsby aka47 - Firmware - experimental, borrowed, and future
Something I just noticed rummaging through G-code defs etc. Makerbot and Repg is using M109 for the bed temp not the extruder temp. M109 P1 Snnn.n should be equivalent. Something to watch out for I guess. As anything generating G-code may well be using the Makerbot numbering, particularly Repg.by aka47 - Firmware - experimental, borrowed, and future
That sounds like a good compromise.by aka47 - Firmware - experimental, borrowed, and future
On PID values. Yes I fully agree they need to be different for each heater (bed versus extruder). They are both set to the same though in the file heater.c via the default PID values. My understanding then is that :- They need to be changed manually after download, via M commands. As they are by default the same. Might be worth documenting that somewhere for newbies to pick up on. Looking tby aka47 - Firmware - experimental, borrowed, and future
OK I use mechanical micro-switches for my end-stops. Attached is a schematic. It less clever in reality as the capacitor and resistor are soldered directly across the micro-switch contacts and no PCB is needed. It uses the same VCC and GND feeds that an Opto endstop would use. Basically when in a stable (at end-stop, no at end-stop) state the output is either hard switched to GND or VCC as aby aka47 - Firmware - experimental, borrowed, and future
Guys as ever great things happening here. Just been having a play with the extract.py script. and found a couple of things. 1. The script as it comes from the repository is missing the execute permission so won't run on Linux/Unix unless this is set first. ( chmod +x extract.py ). It is probably worth considering setting the permission on the file in the repository though. Like it is for the oby aka47 - Firmware - experimental, borrowed, and future
Hi sheep. A firmware worth looking into at the moment is the Teacup Project. These guys have a branch that is producing code for SD card support. (All in C, but targeted at Arduino based chips & boot-loaders) I think Casaino was attempting to port this to ARM. not sure how far he got though. I think there is guy over there called Architect who is looking into a separate control panel. Whiby aka47 - Firmware - experimental, borrowed, and future
Triffid. Thanks for the pointers to libreprap, yup source to your invocation of socat would be useful. Although I don't intend to use socat to keep the dependencies low'ish (although might do yet as it is early days yet, just seeing where it goes). ncurses and cdk are calculated hits on the dependencies thing. They arguably contribute more forward progress than they cost and are pretty much staby aka47 - Firmware - experimental, borrowed, and future
Alan Fortunately you don't have to be, but finding out can be revelatory. This might be useful:- Cheers aka47by aka47 - Plastic Extruder Working Group
Guys Just initialized a repository on github for the code I have written so far for a text (NCurses) based bit of host-ware specifically targeted to work with Teacup. There really is not much in it as yet except a couple of windows and a minimalist menu. But it is a start. Initialy it is intended to be a simple machine controller that will download gcode files at the machinery and gove a degby aka47 - Firmware - experimental, borrowed, and future
Yup Nice prints Sublime. I hope I can get mine to be as good when I have got everything working. Triffid Sir, Re M6 T0, I wasn't aware either. It is what Skeinforge 39 is turning out though (Could be a makerbotism). Thanks for the tip I can probably use the replace csv thingy to change these. Will fetch down Bens latest too. Can't be far off now. Most of the issues so far appear to be gettinby aka47 - Firmware - experimental, borrowed, and future
I might have found it I activated Dimension in the profile and I now get something with E parameters. Off to do some more testing.by aka47 - Firmware - experimental, borrowed, and future
If I compare this with the code that Architect uploaded for comparison. G1 X8.89 Y-8.89 Z0.15 F1800.0 E17.78 Architect's code clearly shows the E values for each G1 So I think RepG245 & Skeinforge39 are not passing information between them that tells Skeinforge to generate 5D G-Code. Consequently no extrusion.by aka47 - Firmware - experimental, borrowed, and future
OK more testing done. Sublime I tried changing the max and min stuff as suggested and it didn't work unless I manually homed the extruder tot he centre (which defeated the purpose a little) emt However setting the multiply option in Skeinforge with a cell size of 1 did work as the head now went to the center of the bed before starting (I dialed in 100 by 100 for my 200 by 200 bed) and the motby aka47 - Firmware - experimental, borrowed, and future
Sure I agree. However, having the build origin centered in the X & Y Axes of the Build Space and calculated from the build envelope dimensions may be arguably applicable to more of the permutations than perhaps not having it so. RepG just happens to be one of them. I would certainly be concerned about going a route which made sense for only one permutation at the expense of all the othersby aka47 - Firmware - experimental, borrowed, and future
Guys Awesome. Architect & Sublime. Thanks for the pointers, I am using skeinforge39 and found it creates the new profiles in ~/.replicatorg/sf_39_profiles ~/ being the default home directory (sorry had to explain for windoze folks) I have hacked the two gcode files and now get something that looks more sensible so hoping to try this out tomorow sometime. Sublime Tweaking the origin toby aka47 - Firmware - experimental, borrowed, and future
Thanks for those. You are a star. I have had a look through the G-code and will check up on where you suggested the homing instructions are coming from. The G-code looks to increment the Z axis from (pretty much nearly zero) upwards. A definite improvement over my own attempts so far. The X and Y axes look to be working around a reference point with +ve and -ve displacements though. But thereby aka47 - Firmware - experimental, borrowed, and future