Quantcast

comments edit

En préparant un projet de démo AngularJS + Bootrap + Web Api (article a venir !), j’ai eu besoin de générer des données de test. Après quelques recherches infructueuses, j’ai donc choisi de monter mon petit projet. Ca tombe bien, j’avais envie de coder un petit projet “utilitaire”, et de me faire plaisir avec une API de type “Fluent”.

Une première version est dores et déjà disponible sur github. J’aurais l’occasion de vous en reparler dans un article à venir (ca commence a faire beaucoup d’articles à venir…).

Apres l’avoir référencé “manuellement” dans mon projet de démo AngularJS, je me suis demandé comment optimiser le déploiement de mon générateur de données. Ca tombe bien, j’avais envie de créer un package nuget.

Etape 1 : création du projet

Rien d’exceptionnel, une solution Visual Studio standard, avec l’option “Activer la restauration des packages nuget” activée, ceci afin d’avoir un nuget.exe accessible facilement en ligne de commande depuis le dossier de la solution.

Etape 2 : création d’un compte Nuget.org

Ici, toujours rien de complètement fou, on s’enregistre, et on note bien l’api Key, pour l’activer sur le poste de développement.

Etape 3 : création du fichier .nuspec

Ici, les choses peuvent un peu se compliquer, selon le temps que l’on souhaite consacrer à la documentation Nuget. Pour faire simple, il faut initialiser un fichier .nuspec avec la commande suivante

.nuget\nuget.exe spec

Ensuite, il faut déplacer ce fichier dans le dossier du projet qui va servir a générer le package, et lui donner le même nom que le .csproj :

2013-11-30-nuget

Enfin, il ne reste plus qu’a modifier le contenu du fichier nuspec pour l’adapter a votre projet.

Etape 4 : publication manuelle

La création du package est maintenant possible, avec la commande

.nuget\nuget.exe pack SampleDataGenerator\SampleDataGenerator.csproj

Nuget s’appuiera sur les .csproj et .nuspec pour générer le package.

Il ne reste plus qu’a l’uploader sur nuget.org.

Etape 5 : le serveur d’intégration continue

J’ai choisi TeamCity pour remplir ce rôle, principalement en raison de sa simplicité, et aussi parce qu’il est développé par JetBrains (auteurs de ReSharper, donc pas vraiment des amateurs).

Je ne rentre pas dans les détails de l’installation, du type next, next, next. Comme j’exécute TeamCity sur mon poste de travail, J’ai juste changé le compte d’exécution des services pour “System account”. Sur un serveur dédié j’aurais crée un user spécifique (car c’est très mal de faire tourner des services avec System account !)

Une fois le serveur installé, il ne reste plus qu’a se rendre sur l’adresse http://localhost (avec le port spécifique si vous l’avez configuré ainsi) pour finaliser l’installation.

Ensuite, il faut créer un nouveau projet, avec un configuration associée. Ici, les valeurs par défaut feront très bien l’affaire.

Une fois le projet créé, il faut lui associer un contrôle de code source. TeamCity supporte git nativement, l’url présente sur la home de votre projet doit être reprise :

Url Github

Petite subtilité, j’ai repris l’exécutable fourni avec le client github (dans C:\Users\Login\AppData\Local\GitHub\PortableGit_XXXXX) et je l’ai copié dans un dossier spécifique :

Chemin vers l'exécutable Git

Les étapes de build sont également aisées à configurer (je repense au temps passé a pondre du xml pour CruiseControl.NET…). La première étape est la compilation. Si vous avez bien paramétré le contrôle de code source, vous pouvez déjà choisir le fichier .sln avec le picker a droite du champ “solution file path” :

Configuration du build

Nous arrivons maintenant aux étapes concernant nuget. L’ajout d’une tache “Nuget pack” vous aménera a l’écran suivant :

Paramétrage de la tâche Nuget

Ici, il faut bien penser à aller dans “Nuget settings” pour télécharger un client nuget pour TeamCity. Il est également possible de publier les packages nuget dans un feed local au serveur teamcity. Ce qui peut s’avérer plutôt pratique pour les développements en entreprise… Il est aussi à noter que le package sera généré avec un numéro de version correspondant par défaut au numéro de build. Ce qui s’avère pratique pour les mises à jour du package.

Enfin, la publication se fait avec la tache “Nuget publish” :

Paramétrage de la tâche de publication

Une fois le build complété avec succès, on peut vérifier la présence du package sur nuget.org :

Historique de publication Nuget

comments edit

Après quelques dizaines d’heures d’impressions, j’ai eu un souci avec le charriot Y : celui-ci ne bougeait plus. La vis qui bloque la poulie sur l’axe du moteur s’était desserrée, et l’axe tournait donc dans le vide.

J’ai donc resserré celle-ci, et je l’ai fixée avec un point de cyanoacrylate. Cette solution ne me satisfaisant qu’à moitié, j’ai commandé des courroies T2.5 ainsi que les poulies en aluminium correspondantes.

Une fois le montage et la calibration effectuée, je n’ai pas remarqué d’amélioration notable dans la qualité des impressions. Mais au moins, les poulies sont en métal et ne se sont plus desserrées depuis…

comments edit

Comme vu précédemment, la planéité de la surface d’impression joue un rôle très important dans la qualité des impressions. Les imprécisions de la première couche se propageant aux couches suivantes.

Avec le PLA translucide fourni, je n’ai pas eu de soucis d’adhérence, en imprimant à 175°C/65°C (extrudeur/lit).

Par contre avec du PLA de couleur, les soucis sont vites arrivés : même en imprimant la 1ere couche a 5mm/s, et quelle que soit la hauteur initiale, la pièce se détachait au bout de quelques couches. D’après le fournisseur du PLA (Imprimante 3d France), la température conseillée est de 210°C/105°C. Mon plateau chauffant ayant du mal a dépasser les 80°C, 105°C me paraissaient vraiment beaucoup.

Après de nombreux essais sur du scotch bleu plus ou moins chauffé, un camarade a eu l’idée de poncer la plaque de verre, ce qui a résolu tous les soucis d’adhérence.

comments edit

D’apres le calculateur de Josef Prusa vous pouvez commencer avec les commandes suivantes :

M92 X64 ; calibrate X M92 Y64 ; calibrate Y M92 Z2267.72; calibrate Z M92 E533 ; calibrate E

Ces commandes sont a placer dans la section “Start GCode” de slic3r :

Paramétrage slic3r

L’extrudeur

La première chose à faire est de bien calibrer votre extrudeur. Sur une extrusion de 10cm, l’erreur doit être en dessous des 0.5 mm !

Dans un premier temps, dans l’onglet “Controle manuel” de Repetier, envoyer la commande “M92 E533” et extruder ensuite 10mm :

Calibration de l'extrudeur

Ensuite, placer un repère sur le fil a environ 10cm (un bout de scotch fera bien l’affaire), et mesurer. Pour la mesure, j’utilise un pied a coulisse numérique, posé sur le guide fil de l’extrudeur, pour le stabiliser :

Une mesure relativement précise

Ensuite, extruder 80mm, soit en une fois, ou bien en demandant plusieurs extrusions de 10mm. Pensez bien a attendre la fin d’une extrusion avant de cliquer a nouveau sur le bouton. Sinon, l’imprimante peut réagir de manière étrange.

Une fois l’extrusion finie, mesurez a nouveau. Si la différence entre la mesure avant extrusion et la mesure après ne correspond pas à 80mm, faites un produit en croix pour obtenir la nouvelle valeur M92 Exxx a envoyer. Envoyer la nouvelle valeur, extrudez 10mm, et recommencez les mesures jusqu’à obtenir un résultat avec moins de 0.5% de marge.

Les axes X et Y

Pour calibrer les axes X et Y, j’ai utilisé ce modele thingiverse. Une fois les axes calibrés j’obtiens une précision en dessous du 1/10e de mm!

Une mesure relativement bien calibrée

L’axe Z

Pour l’axe Z, j’ai laissé la valeur par défaut du calculateur, pour le moment…

comments edit

Parfois, pour tester rapidement un exemple d’application JS, il peut être utile de pouvoir lancer rapidement un serveur web.

Entre en scene IIS Express, et sa ligne de commande… Encore mieux, un petit fichier de registre a appliquer, pour pouvoir lancer IIS Express depuis l’explorateur windows : IIS Express Here.

Et quand on a fini de tester, il y a juste a fermer la console ouverte… Pratique.