We had a kind of meetup last year with 5w people and reprap/makerbot operator (the printer of the hacklab mendel parts) at Tampere: So maybe here in Helsinki this time.by elmom - Finnish RepRap User Group
That's Private Message See the link next the the nick of the poster...by elmom - Finnish RepRap User Group
I have built a Sells mendel for Helsinki Hacklab, but unfortantely it's not fully functional ATM. I did print the parts for Prusa with it though. I'll be glad to help.by elmom - Finnish RepRap User Group
Here's my page about finnish repraps: Here's about prices of hardware, I can give edit rights to interested people: K-Rauta is expensive, except for nuts. Here are some hint's about hardware stores, additions are welcome: Hex head socket screws are nice, but non-flat philips heads ('koneruuvi', 'kupukantainen') are much easier to come by and cheaper here in Finland. I've mostly assembled aby elmom - Finnish RepRap User Group
macegr Wrote: ------------------------------------------------------- > So...there's still a lot of work to be done on the > software end. I ended up NOT using Repsnapper, I > may need to try again, but it kept stalling out > (suddenly the toolhead would just sit there, > clicking over by one step every second or two). It > may have been something I changed in > Skeinforge..by elmom - Firmware - experimental, borrowed, and future
Also, for those wanting simple terminal gcode sending, I can recommend gcdump from . It has cmake as a build time dep, but other than that, it will fit in any linux sytem. I can also help with this piece of software.by elmom - Firmware - experimental, borrowed, and future
Yes, I just tried with master and gtk2 branches of RepSnapper, it worked. Just a ramps1.1 board, nothing attached. Config from the config.ramps.h, with changes from latest config.h.dist merged in. Windows isn't abandoned, there just aren't any people around with windows building powers With version 2.0 (gtk2 branch) nightly builds for the three platforms are coming... I'm on #repsnapper and #Pby elmom - Firmware - experimental, borrowed, and future
BodgeIt Wrote: ------------------------------------------------------- > > @ Architect > > The connection times out with No connection using > Teacup with Repsnapper. > > During the time it takes for the time out you can > send commands (ie before time out occurs ) > > These commands can be used.. Jog X , jog Y jog Z > , home X,Y or Z Home All heater on . &gby elmom - Firmware - experimental, borrowed, and future
BodgeIt Wrote: ------------------------------------------------------- > Is it possible to use the Teacup firmware with > Repsnapper? > > I have made a custom build to suit my Gen3 > Motherboard 1.1 ~ initial coms will work till the > connection times out indicating. > There is a Comms protocol diffrence of some kind > or my custom build is affecting the serial comms. >by elmom - Firmware - experimental, borrowed, and future
Triffid_Hunter Wrote: ------------------------------------------------------- Then you just need to convince > your host-side talker to supply this information > at the end of a print, or whenever it might be > appropriate. Who wants to send patches for repg, > reprap host, repsnapper etc to show returned > messages during/after a print? > RepSnapper prints all comms to a logby elmom - Firmware - experimental, borrowed, and future
nophead Wrote: ------------------------------------------------------- > Standards are always the lowest common denominator > and hold back progress. Not a good thing at all in > a project that is constantly evolving. I think this was hashed enough on reprap-dev, most of us would like for firmwares and host softwares be comptible with each other as much as is *reasonable*. Markus is rigby elmom - Firmware - experimental, borrowed, and future
Triffid, yes, making libreprap accept all the used formats should be done (will do), but following the actual standards definition is still the right thing to do. or change the standard to something that is really used (and please ask others beforehand). There is a reason the standard is there in the first place. To make everyones life easier. Elmoby elmom - Firmware - experimental, borrowed, and future
Triffid. FiveD, which is the reference implementation, uses "rs n" instead of "rs Nn", and that's what is the most straight forward interpretation of the standard. RepG should except that too, and since it's compatibility to FiveD is newer than other host software, it definitely shouldn't dictate the defined protocol. Nontheless, libreprap should be compatible with both, since it should be easy.by elmom - Firmware - experimental, borrowed, and future
What other firmwares send? What does the java host expect? If there is some consensus, then that should be clarified in the protocol standard and implemented in libreprap. Going forward, libreprap should be the reference host side protocol implementation to test with, and hopefully the implementation used by all host software. I'ts a proper standardization effort, and I'm debugging for/with RepSnby elmom - Firmware - experimental, borrowed, and future
Triffid_Hunter Wrote: ------------------------------------------------------- > elmom Wrote: > -------------------------------------------------- > ----- > > Reporting a bad incompatibility: The firmware > sends > > something like "rs N2 Expected***\nrs 1\n" which > breaks > > the more naive host-side parsers. Is that > message > > really necessary? >by elmom - Firmware - experimental, borrowed, and future
Reporting a bad incompatibility: The firmware sends something like "rs N2 Expected***\nrs 1\n" which breaks the more naive host-side parsers. Is that message really necessary? At least remove the "rs" from the error message.by elmom - Firmware - experimental, borrowed, and future
Could someone add the commented out programming baudrate of 115200 for atmega2560, and a switch to use stk500v2 versus stk500v1, as that is what Arduino Mega 2560 default bootloader requires. So, I got the gcode parser loop working inside that particular board, improved the wikipage docs about that. To the people discovering how to program the firmware, please add you findings as clarificationsby elmom - Firmware - experimental, borrowed, and future
Traumflug Wrote: ------------------------------------------------------- > the problem being that the DDA_QUEUE will process > N0, N1, N3-N5 skipping N2 until it is resent by > the host. in which case the host seeing a "rs" > request resets the line numbers it is sending to > start with the "rs" request line. In effect > resending lines N2-N5. if each of these lines are > cheby elmom - Firmware - experimental, borrowed, and future
Triffid, Traumflug, other devs, you want to look into , it's the future of host side comms. They are especially interested about the current APIs and the best possible API. And issues about line numbering, resends etc.by elmom - Firmware - experimental, borrowed, and future
The Java host software is buggy. Try RepSnapper, it might be less buggy for you I can help with that client software, especially if you come to #repsnapper@freenet (IRC). I haven't actually gotten this firmware to work, should try again now that it seems to mostly work. Btw. is homing (G28) working yet? I'd like the ability to calibrate the position automatically before I switch to this for proby elmom - Firmware - experimental, borrowed, and future
Traumflug Wrote: ------------------------------------------------------- > Tested example config.h files for both boards > would be great. > > How would I test a config with neither having a > standard Gen3 electronics nor a standard (if that > even exists) Mendel? > Well, putting the proper #define's and having it compile would be great. Now I'm actually successfully usiby elmom - Firmware - experimental, borrowed, and future
Traumflug Wrote: ------------------------------------------------------- > Could someone (Triffid?) make the gen3_merge > branch code compilable fot gen3 (with correct > defines in config) with the arduino env? > > That's obviously currently in the works on the > branches with "gen3" in the name. Regarting a > config, putting this into a > config.h.gen3-mendel.dist wouldby elmom - Firmware - experimental, borrowed, and future
Btw. the compiling in the Arduino env complains about the copier.* code, which should not be included. Removing them fixes that particular issue, but what would be the real fix? I tried in my fork (the temp branch currently) making the makefile copy the appropriate files into a build dir. That replaces the need to have symlinked files (what about windows?) for the extruder board also. For the otby elmom - Firmware - experimental, borrowed, and future
Could someone (Triffid?) make the gen3_merge branch code compilable fot gen3 (with correct defines in config) with the arduino env? I would love to use the makefile, but can't seem to be able to upload the code. Get the usual error of board not responding and syncing error. If you could give any pointers on how upload the .hex, it would rock my world Are you able to upload with "make program" ?by elmom - Firmware - experimental, borrowed, and future
Triffid seems to be doing the merging now in the new gen3-merge branch? I'm happy if/when master magically starts to work on gen3by elmom - Firmware - experimental, borrowed, and future
Traumflug Wrote: ------------------------------------------------------- > Does Github allow you to rebase your fork, then? I > mean, if you just forked, you get something like > this: > Rebasing commits that are pushed to a public repo is discouraged, and I don't think github allows anything besides adding and deleting branches. Do the duplicates really matter? Is occasional birecby elmom - Firmware - experimental, borrowed, and future
The define is in config.h.dist (as it should be) in my commit.by elmom - Firmware - experimental, borrowed, and future
> As the main loop doesn't do anything but decoding > GCode, the heart beat is in the stepper interrupt. > Of course it's so fast you typically can see a > dim, constant light only. Higher motor speeds or > acceleration ramping in action makes the LED a bit > brighter, as this in more computing intensive. > Stopping all motors makes the light going off. > So is the debugby elmom - Firmware - experimental, borrowed, and future
Now my public master branch should include all the atomic and noninvasive improvements that I've made so far. You are welcome to pull them.by elmom - Firmware - experimental, borrowed, and future
Traumflug Wrote: ------------------------------------------------------- > elnorm, that's a great idea. Please try to break > down the changes into small patches by > functionality, because this is the only way to > keep master working reliably. I just tried to > rebase the gen3 branch to a more recent master and > had to give up. Too many unrelated changes in one > patch, toby elmom - Firmware - experimental, borrowed, and future