Show all posts by user
Les 2 thermistances B57550G104J et B57560G0104F ont les mêmes caractéristiques (je viens de comparer les datasheets). Donc la table (répétée 2 fois) dans le fichier ThermistorTable.double.h de Teacup devrait te convenir Tibo. La ligne de commande permettant de créer la table est donc aussi la bonne.
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
une très bonne idée le collier je trouve… une bonne solution très chère serait une "vraie" colle thermique du genre de celle-là : http://fr.farnell.com/fischer-elektronik/wlk-5/conducteur-thermique-adhesif/dp/1211723…
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
Côté pololus, je n'ai pas encore une énorme expérience de l'impression avec eux (sur la Gen7) mais pour moi, réglés avec la tension de 0.47V ils ne chauffent pas démesurément, aucune perte de pas des moteurs qui serait due à la protection thermique intégrée aux pololus (plusieurs impressions de plusieurs heures déjà). Je n'ai pas mis de radiateurs (je ne sais pas comment utiliser cet espèce d'aut
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
l'application du patch a échoué…
patching file Teacup_Firmware/dda.c
Hunk #8 FAILED at 753.
1 out of 8 hunks FAILED -- saving rejects to file Teacup_Firmware/dda.c.rej
ce qui confirme que ça ne pouvait pas compiler pour toi, nos dda.c étant différents… tu peux essayer la version du FW citée plus haut… qui entraîne ce défaut de géométrie si E_STARTSTOP_STEPS est supérieur à 0… pour tout fichier s
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
aaahhh nous n'avons sûrement pas la même version du firmware, les 2 dda patchés n’entraînent pas d'erreur de compilation chez moi. Différence de version confirmée aussi par E_STARTSTOP_STEPS à 289 dans ton config.h, une telle valeur entraîne un énorme défaut de géométrie des pièces imprimées avec mon firmware (E_STARTSTOP_STEPS est donc à 0 ici-même à Clermont-Ferrand (City)).
ma version est l'a
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
paoparts Wrote:
-------------------------------------------------------
> j'avais zappé ce thread , pourtant je suis attentif ...
L'actualité est tellement dense qu'il est impossible de tout suivre, bdnnd (soyons polis) !…
> je vais pouvoir augmenter la vitesse de
> transmission et passer en mode stratosphérique ...
Peux-tu me dire si finalement ta question à l'origine de ce thread é
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
Many thanks for your research into firmware and the time you spent for this! I should'nt have the idea to investigate the firmware… just found the switch statement into gcode_process.c…
After further trys, the only good value for E_STARTSTOP_STEPS is 0, the geometry error comes back when the value is bigger. As you said a ghost effect…
by
François Delègue
-
Firmware - experimental, borrowed, and future
Thanks for your answer… which proudly solved the problem…!
But I don't figure out why an E parameter plays with X & Z toolpaths, how did you guess that?
I suppose we suck back filament to avoid oozing; now my E_STARTSTOP_STEPS equals 0, I'll try to increase it little by little before this crazy geometry comes back…
by
François Delègue
-
Firmware - experimental, borrowed, and future
Bonjour,
j'ai eu moi aussi un problème d'arrêt d'impression, systématique et toujours au même endroit du Gcode, avec Teacup et Gen7, qui n'était pas dû à un défaut de communication entre ordinateur et reprap mais à un bug dans Teacup (dépassement d'un entier), non encore réglé aujourd'hui (commit 85e29e8c91, GitHub Gen7 branch ).
Ce problème fait l'objet d'un thread, et est réglé par l'applicat
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
Hi all!
I am changing my Mendel electronics & FW to Gen7 & Teacup. Making my first test prints, I could'nt get my hexagone without a "big bug": one of the faces is replaced by a descending wall going to the center of the bed. Using Multiply plugin into Skeinforge, this wrong face goes outer the hexagone, to the center of the bed too. After a long long search I understood that my print w
by
François Delègue
-
Firmware - experimental, borrowed, and future
Je précise mon "plus simple encore" : si on a comme moteurs des SY42STH47-1684, qui sont presque un standard : inutile de faire le calcul car la tension à mesurer (0.47V) est celle de l'exemple donné (moteur de 2.8V et 1.68A).
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
did you adjust pololus ?
http://reprap.org/wiki/Gen7_Board_1.4#Adjusting_the_Pololus.2FStepSticks
et, plus simple encore :
http://reprap.org/wiki/Sanguinololu#Pololu_drivers_current_limit_configuration
Autres idées : si ton axe bizarre est X ou Y, tu peux inverser les connecteurs de ces 2 moteurs pour voir comment le pb se répercute, ou permuter 2 polulus sur la carte mère…
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
Le contrôle de la température du plateau est indispensable, donc la thermistance aussi, inutile de trop chauffer le plateau (environ 55° pour du PLA, 110° pour de l'ABS). J'imagine qu'on peut s'en passer pour des 1ers essais, si le firmware n'attend pas que la température du plateau soit atteinte avant de lancer l'impression (ne pas commander alors de chauffage du plateau dans le Gcode, ou ne pas
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
Bonjour,
les courroies doivent être le moins tendues possible tout en transmettant le moindre mouvement des moteurs, je teste ça en tournant très légèrement le pignon d'un moteur (même pas un pas, un demi à peu près) et en regardant si ce léger mouvement est transmis au charriot X ou au plateau (Y). La courroie est toujours plus tendue sur l'axe Z de la Mendel car elle doit transmettre plus de f
by
François Delègue
-
RepRap Groupe d'Utilisateurs Francophone
My experience is:
-alternative X motor bracket design don't give enouth attachment between belt and pulley
-first X motor bracket design is said to brake the belt after some printing time
-if we often have the same belts, we don't often have the same pulleys, and there often is backlash between belt and pulley (various backlashs for all of us)
So:
-I added 2 bearings to the alternative X motor b
by
François Delègue
-
General Mendel Topics
I mounted the alternate X motor bracket with 2 more bearing as illustrated into my last post (photo): all is ok as with original X motor bracket, squares are squares.
So I suppose now that the problem was coming from the size of the teeth of the pulley, which are only 1.7mm width: it is not very much, and it's not a problem if the belt turns enouth around the pulley.
by
François Delègue
-
General Mendel Topics
@nophead: yes I have a belt with wires in it, used with your pulley design (many tanks for it!).
Belt from Ultimachine and pulleys profi-printed from Mendel-parts.com.
Reading all your posts: perhaps the problem was coming from a too little belt/pulley hanging into the alternative x-bracket,, not from the side of the belt. Perhaps adding 2 bearings, fixed with 2 of the motor screws, would fix t
by
François Delègue
-
General Mendel Topics
In other words, when belt runs by teeth side on the bearings, the tension is continuously changing because of sequences of "full and empty" belt. So the belt travels a very little less X distance. Otherwise I can't explain why I have now a perfectly working Mendel with the original X motor bracket, that I did'nt have with the other one.
Of course I prefer a working reprap with a belt to change s
by
François Delègue
-
General Mendel Topics
Hi all,
I was a long time with circles not circles, and squares not squares with Mendel, more precisely said: X lenght was always too little. For example a 20mm square was printed 20mm into Y direction and only 19,5mm into X direction. Accordingly circles were not circles...
After many months trying many things as you can imagine I found THE solution!
I was using Alternate X motor bracket. Wit
by
François Delègue
-
General Mendel Topics
Thanks for your advices nophead and Nudel, I could skeinforge this file now. I was taking for a bug what was an "high amount of triangles", conducing to a huge carve process time.... each day something to learn!
by
François Delègue
-
Skeinforge
Hi everybody!
there is a Mendel alternative part (xaxis-motorbracket_1off.stl) which can't be treated by Skeinforge, because of a veeeeerrrryyyy long process time, leading to a bad slicing of the part.
I tried many things (several Linux machines, an OS X one, repairing the file with Netfabb Cloud Service, opening it into several softwares (OpenScad, ReplicatorG, Pleasant3D, Netfabb basic) then
by
François Delègue
-
Skeinforge