Re: Alimentation de canton à travers le port USB

[Tibrus]

Ok merci dans un premier temps à Pierre pour la différence entre le L293D et L293.
Effectivement c\'est bien du PWL qui pilote le système UTS. L\'auteur essaye de réactiver son compte sur RMF pour venir répondre.

Moi pour la mesure de déroulement, je verrais ceci. Tu prends l\'heure au moment ou tu lances ta commande. Elle agit sur sur relai. Celui-ci colle et mets à 1 une entrée qui est remontée au programme. A ce moment la tu reprends l\'heure. Tu en fait la différence et tu as le temps aller/retour. Bien sur, il faut prendre une valeur pour le temps avec le plus de digit.

Ensuite pour le programme, ton idée n\'est pas bête. Si on part du principe que le Pc quand il va piloter le train ne fera que cela, il pourra très bien voir tourner Prg1 et Prg2.
L\'idée de faire gérer certaines choses par le Pic, serait de rendre le système sans PC. Prg1 serait dans ce cas remplacé par un vrai TCO qui enverrait les autres au PIC. Et il serait possible de remplacer le TCO par une carte Entrées/Sorties que piloterait ton programme.
Ensuite si tu maîtrises la programmation PC, autant tout faire dessus. Car le langage du PIC sera à apprendre. Cela reste de l\'assembleur mais propre au PIC. Maintenant pour le Fun comme je dis souvent, cela peut être un beau challenge pour toi

[ama0000]

Pierre, Tibrus,

J\'ai fait quelques tests pour estimer la durée de transfert entre le Pc et une carte de Decision Computer (32 relais).
J\'ai fait des simples boucles imbriquées en envoyant un byte (8 bits) à chaque fois en alternant, remise à zéro du bit précédent ou pas. Pour info le bout de code :
For k = 0 To 19 \'20 tours !
For i = 0 To 3 \' 4 banks de relais
z = 0
\'hid_SetDigitalByte(hDevice, i, z) \' raz de la bank en cours
For j = 0 To 7
z = z + 2 ^ j
hid_SetDigitalByte(hDevice, i, z) \'allume le bit suivant et garde l\'état précédent
\'hid_SetDigitalByte(hDevice, i, 2 ^ j) \'allume le bit suivant et éteint de précédent
Next
Next
Next

J\'obtiens une moyenne de 1 ms par exitation de relai. Je n\'ai pas réalisé la même chose avec l\'USB IO/24, mais je suppose que les temps de réponse seront sensiblement les mêmes.
Donc si je veux une lectures / écritures toutes les 1/4 de secondes, le système peut lire / écrire un maximum de 250 points. En prenant en compte que je devrais avoir une cinquantaine de points de lecture, il reste, avec une marge de sécurité 150 points en écriture. Sachant que je devrais avoir 6 trains en circulation en même temps et à raison de 7 bits par TLC (par exemple) il doit y avoir de la marge ..,

Suite à la remarque de Pierre sur le L293 je vais reprendre cette partie...

Concernant le PIC, aucun soucis de programmation, le langage n\'est que le vecteur de l\'algorithme. Et si celui ci est pensé avec les composants du bord, il doit y avoir moyen de s\'amuser. Par contre, je ne m\'y lancerais que si j\'ai besoin de déléguer l\'exécution d\'ordres, comme par exemple le ralenti ou l\'accélération d\'un train ...

A plus tard !

Belle nuit

Al\'

[Jean-Luc92]

Pour gérer 16 cantons un PIC 16F873A à 20Mh est un minimum pour gérer autant de signaux PMW.

Sur le site http://www.la-tour.info/uts/uts_index.html
J\'ai repris l\'idée d\'Ulysse pour améliorer ce montage.

Elaborer un nouveau modèle de conduite de réseau et construire un nouveau montage à partir de zéro me parait aventureux. Rien que pour passer de la version d\'Ulysse à ma version 3.2, il m\'a fallut un an de travail.

J\'ai réfléchi pour connecter le système UTS via un port USB, mais cela n\'est pas évident.
Avec la liaison série, j\'arrive à émettre 55 octets et recevoir en même temps 25 octets à 38400 bps.
L\'échange des données entre le PC et le PIC ne dure que 14 msec, ce qui permet de modifier la vitesse sans à-coup car le rafraichissement de la consigne se fait presque en continue.

Ce n\'est pas sure que la liaison USB[1] soit aussi rapide et réactive.

Mon montage s\'adresse à la gamme \'N\'. Pour la gamme HO il faudrait des ponts en H plus puissants. En version 3.2, les ponts en H sont en roue libre et ne forcent plus la fin du créneau au 0 volt. Ils chauffent nettement moins.

A+

[ama0000]

Jean-Luc,

Merci pour ces infos.
Mais car il y en a un !!! Je vais poser des questions de débutant et de béotiens car là je suis un peu perdu ...

1) USB ou port Serie (RS 232) : je ne comprends plus la différence : USB est un port serie (il n\'y a que deux fils !) ... Donc quel est la différence pour une carte de type UTS
2) Usb ou RS232, dans les deux cas il faut \"reformater\"/\"interpreter\" les bits entrant / sortant ... Oui / non
3) 80 octets soient 640 bits (hors bits d\'accompagnement) en 14 ms ... ben perso je dis pas mal ... Peut mieux faire ou faut il mieux faire ?

Autres questions !

1) Pic ou pas Pis ? Je n\'ai rien contre le Pic et rien ... pour !!! Pourquoi ? Pour moi, corrigez moi si il le faut, m\'enfin avec douceur ;-), le proc d\'un Pc est plus puissant qu\'un Pic, certes assisté par les uart et autre de la carte mère ... mais au final, si on utilise un système d\'exploitation \"pauvre\", utilsant peu de ressources (linux ??) la force de frappe est là ... Oui / Non ?

2) comment obtenir une accélarération et un freinage réalistes ? Interval de temps entre chaque pas de vitesse ?


Je veux banir potars, interrupteurs ... et n\'avoir qu\'une souris ou un écran tactile à manipuler ! Ok ça se discute, mais c\'est ma ligne directrice ! Je sais, pour être plus exact, je peux, détecter un convoi (merci amfn), basculer les aiguilles (merci rob), varier la vistesse d\'un convoi (merci à ceux précédemment cités et vous qui répondez à ce post : Pierre / Tribus / Jean Luc). Ce que je veux réaliser est la sécurisation du réseau : tel canton à telle vitesse maxi, canton Buzy implique règle de gestion des précédents, sécurisation des \"cantons aiguillages\" ... Plus tard je verrais pour faire des routes de trains ...

Juste pour vous rappeler mon niveau : je suis informaticien, spécialisé sur les bases de données (oracle), infocentre et autres réjouissances de ce type ! Mon unité de temps est ... la paire de secondes, de plus audoditacte en électronique ... donc \"esclave\" des datasheets et expériences parfois malheureuses ... mais c\'est formateur !
De plus j\'utilise du matériel de récupération récent\" : 3 à 4 ans maxi ...

Alors pour finir la question qui tue : Faut il utiliser un Pic avec des ponts en H ou des TLS7226 ... mais avec uo sans Pic pour gérer la vitesse celui qui me répond Pic serait sympa de m\'indiquer avec quelle plateforme (évolutive) faire des tests !

Merci pour votre aide !!!!

A bientot

Al\'

[Jean-Luc92]

Bonjour, pour une carte UTS il faudrait soit un convertisseur USBsérie soit reprogrammer un Pic gérant une prise usb.
Sur UTS 3.2 un transfert complet dur 14 ms, avec les temps d\'attente et la capacité limité de mon PC pour gérer un tour complet de programme UTS, le rafraichissement sur le réseau est fait tout les 80 ms, soit 12 fois par seconde.

UTS V1 avait une fréquence de rafraichissement de 200ms, beaucoup trop lente à mon gout. Les démarrages et arrêt n\'étaient pas assez progressifs.

Le PC est plus puissant qu\'un PIC, mais je demande à voir comment un PC peut traiter en temps réel directement les signaux de 16 (ou 32) sorties PMW à 50 Hz sur 128 pas.

Avec UTS on commande les trains aussi avec des potars et je trouve cela plus pratique.

Si j\'ai le courage je ferais une vidéo sur les possibilités d\'UTS.

La partie protection de canton n\'est pas complètement gérée par UTS. C\'est vraiment compliqué à réaliser.

Par contre la partie déplacement automatique fonctionne bien.

Pour répondre aux questions il me faut plus de temps. A+

[Pierre59]

Bonjour

De retour de vacances, j\'ai fait des essais de vitesse avec l\'USBIO24.

J\'envoie 100 000 fois les commandes \"A1\" puis \"A0\" pour faire \"clignoter\" la pin 0 du port A.

Il faut environ 47 secondes (temps mesuré par l\'ordinateur), soit environ 473 micro secondes pour les deux commandes et une fréquence d\'environ 2100 Hertz (fréquence contrôlée par ailleurs avec un fréquencemètre).

A la louche on peut gérer au maximum une quarantaine de PWM à la fréquence de 50 Hertz, mais avec un PC qui ne fait que cela, il faut aussi tenir compte du fait qu\'il faudra envoyer plus de 2 caractères par commande pour faire l\'adressage.

En pratique cela sera beaucoup moins, car le PC doit gérer aussi d\'autres commandes que celles de PWM. De toute façon pour gérer une PWM avec pas mal de pas (64 ou 128) il faudra une programmation assez sophistiquée pour respecter les timings.

Une idée pour aller plus vite serai de commander 8 PWM simultanement, là on pourrait peut être alors tenir la route.

Cordialement.

Pierre

[Jean-Luc92]

Bonjour, sur le site UTS j\'ai mis à jour le paragraphe \"Les L293D d\'alimentation des voies\" et \"Les circuits de détection d\'occupation des cantons\" de la partie \"1 - Présentation matérielle de la V3.2\".

La vitesse des trains se fait sur 63 pas. Par carte UTS, le PIC gère 16 sorties PWM pour alimenter les cantons, 5 sorties pour commander la position de servomoteurs, 16 valeurs d\'occupation de cantons, 64 aiguillages max, 56 sorties, 48 leds, 80 entrées numérique, 5 entrées analogiques.

Le code dans le PIC n\'a pas de bug connu et fonctionne parfaitement.
Le logiciel sur PC peut être amélioré. Il faudrait qu\'en commande manuelle avoir un bloc automatique pour éviter des collisions. Par contre en mode automatique le programme fonctionne très bien. A+

[Jean-Luc92]

Bonjour, voici mes premières vidéos d\'UTS 2000.

Site mis à jour ici : UTS 2000

Deux vidéos à regarder :
- UTS 2000 - Vidéo 01.wmv
- UTS 2000 - Vidéo 02.wmv
A+

[Pierre59]

Bonjour

Suite au \"posts\" précedents, concernant la gestion d\'un réseau par USB, voici le résultat de mes dernières élucubrations. Il s\'agit d\'un réseau à priori analogique, géré automatiquement et/ou manuellement par un ordinateur, la solution proposée n\'utilise que des circuits intégrés simples sans recours à des micro-contrôleurs. Cette solution offre un maximum de 2048 bits en entrée, un maximum de 2048 bits en sortie et, cerise sur le gâteau, un maximum de 256 commandes PWM (MLI) pour les alimentation (PWM avec une fréquence pouvant aller à 30 kHz). Ces maximums sont assez facilement extensibles.

L\'USBIO24 me semble bien adapté à ce problème à condition de penser son utilisation globalement. Les trois ports (de 8 bits) sont utilisés de la façon suivante :
- Port A : 8 bits d\'adresse (256 cas)
- Port B : 8 bits de donnée (un octet) en lecture ou écriture
- Port C : bits de contrôle

Pour une efficacité maximale tout se fait 8 bits à la fois (). Deux solutions sont possibles une organisation en étoile ou en bus (voir le site de AMFN), la solution en étoile nécessite moins de composants mais son extension est plus difficile (mais les limites sont ici assez élevées).


Pour la lecture (qui se fait 8 bits à la fois) on utilise des \"octal buffer/line drivers\" gérant 8 lignes, il en faut donc au maximum 256 pour obtenir les 2048 bits voulus (8*256), ces circuits ont des sorties \"3 états\" et peuvent êtres connectés en parallèle, mais un seul doit être activé (enable), il faut donc 256 signaux d\'activation. Ces signaux sont obtenus à partir de l\'adresse (Port A) de 8 bits (256 cas) en utilisant des démultiplexeurs \"4 vers 16\" (4 entrées, 16 sorties), un premier multiplexeur décode 4 bits de adresse pour sélectionner un deuxième multiplexeur qui lui utilise les 4 autres bits de l\'adresse. Il peut y avoir au maximum 16 exemplaires de ces deuxièmes multiplexeurs. On obtient ainsi les 256 activations possibles pour les 256 \"octal buffer/line drivers\". Il faut aussi un bit d\'activation sur le port de commande (Port C).


Pour l\'écriture le principe est le même, mais on utilise des \"octal latch\" à la place des \"octal buffer/line drivers\". On obtient ainsi les 2048 sorties. Il faut un autre bit d\'activation sur le port de commande (Port C).


Pour les sorties PWM c\'est un peu plus compliqué, il faut :
- Un oscillateur, oscillant à 256 fois la fréquence de PWM désirée (cela fait environ 8 MHz pour une PWM à 31 kHz), cet oscillateur est unique, il commande le compteur.
- Un compteur 8 bits, comptant de 0 à 255 à la fréquence de l\'oscillateur. Ce compteur est aussi unique.
- Des couples \"octal latch\" et comparateur (8 bits comparés à 8 bits). Un couple par PWM (maximum 256).

Les \"latchs\" sont commandés exactement comme ceux des sorties, un bit d\'activation sur le port de commande (Port C) sera aussi nécessaire.
Le \"latch\" donne la valeur du rapport cyclique demandé, le compteur présente toutes les valeurs possibles de rapport cyclique. Le comparateur compare le rapport cyclique demandé et le rapport cyclique du compteur et génère la PWM. On a donc une PWM sur 8 bits, 256 pas. Il est possible de réduire la PWM à 128 pas et d\'avoir ainsi un bit disponible pour commander le sens du train. Bien évidemment le signal PWM doit attaquer un circuit de puissance (transistor darlington, transistor MOSFET, pont en H, ...). Ce système est très efficace et performant, le l\'ai utilisé sur mon premier réseau, sur le deuxième je suis passé aux micro-contrôleurs.


Voila ce ne sont que des idées, mais tout à fait praticables.

Pierre

[Jean-Luc92]

Bonjour,

Je viens de faire une mise à jour du site UTS au 13/03/2011.

J\'ai apporté des informations supplémentaires, des corrections ainsi qu\'une nouvelle version du programme sur PC. A+

[ama0000]

Bonsoir à tous !
Désolé pour cette interruption de l\'écrit mais la vie pro et privée font que parfois d\'autres priorités arrivent !
Merci à tous d\'avoir continué sans moi.
Je dois dire un merci particulier à Pierre car j\'ai cru à un moment donné être complètement à coté de la plaque. Je m\'explique : Tout ce que je lisais était basé sur du micro proc et un nombre de lignes E/S réduits, donc avec des \"usines à gaz\". Ceci sans être péjoratif pour l\'excélent travail fait sur UTS et autre. Mais là Pierre me me conforte dans l\'idée que l\'on peut travailler avec 1 octet / 8 bits à la fois, 8 informations en E/S en un seul \"tour\" ! Pour moi ce n\'est que du bonheur !
Je continue dès demain dans cette voie.
J\'ai cependant une petite question pour Pierre et Tibrus qui ont échangé sur un détecteur de présence qui \"marche\" dans les deux sens (vu sur le site afmn) : une alim traction en \"marche avant / arrière\" donc en positif et négatif, une alim de détection en 24 v ou alternatif et un 5V pour le ttl. La question de Tribus était pour quoi lorsque la traction est en moins 12 volts, relié à la détection en + 24 volts, alors que le l\'autre \"\"\"fils\"\"\" est au commun, il n\'y a pas court circuit ? Est ce parce que il faut considérer non pas plus et moins mains \"\"\"alim\"\"\" et zéro ?

Merci et à très bientôt

Al

[Pierre59]

Bonjour

Il n\'y a pas de court circuit, les deux tensions s\'ajoutent comme quand on met deux piles en série mais la résistance de 4.7k ne laisse passer que 7.65 mA.

Pierre