ah - oui dans ce cas... (cela dit on peut le faire en petit )
C'est cet aspect que je n'ai pas compris.
Oui j'ai réguliérement, quotidiennement, voyagé en TER.
Imaginons.
Je dois payer une amende avec ma CB.
Je pose ma CB sur l'engin qui vas l'insérer dans le TPE. ça c'est OK.
Je suis le seul à connaitre le code et je le garde secret!
Comment se passe la suite?
Les 5 (4+1) "doigts" que vous avez postionnés une fois pour toutes si j'ai bien compris, ne sont capable de faire qu'un seul code!
Est-ce le mien?
Tous vos clients n'ont pas le même code!
Est ce juste pour developper un objet de tests ou faisabilité?
Et quoi qu'il en soit, comment sur l'objet final le code passera "sans les mains" du cerveau au TPE.
Déja qu'il faudra bien que les mains posent la CB sur la glissiére qui va l'insérer dans le TPE.
C'est juste cela que je ne comprend pas, ais-je loupé une étape?
Pour le reste, ce n'était que des pistes oas forcément judicieuses (attiny, que des solénoidesl).
Bonjour g_daniel
L'Arduino pourrait être contrôlé par de simples ordres "en clair" introduits par le port série ou manuellement par la ligne de commande d'un terminal asynchrone comme le moniteur de l'IDE Arduino.
des ordres comme CARTEIN, CARTEOUT, CODE2351.
L'idéal serait d'avoir déjà le code de la carte d'essai, pour voir la disposition des touches nécessaires sont compatibles avec l'usage de servo.
A+
Cordialement
jpbbricole
Oui c'est ce que j'ai compris. @g_daniel est
Je suppose qu'il veut réaliser un petit automate qui va tester l'endurance de leur produit. Pour cela ils ont une carte de test avec un code connu et ils veulent sans doute tester l'insertion 100,000 fois et taper les codes corrects (et/ou faux ?) 100,000 fois pour voir si tout se passe bien.
Ca doit être quelque chose comme ça!
Du coup il faudra tester l'endurance et la fiabilité du petit automate avant qu'il ne teste l'endurance et la fiabilité de leur lecteur de carte
Ou c'est juste un cas d'école?
Oui
Un robot pour tester le robot
Plutôt que des solénoïdes ou des servos incapables de composer n'importe quel code si la carte doit changer, pourquoi ne pas faire une petite table xy avec un seul solénoïde ou un seul servo.
Bonjour @g_daniel
J'ai fait une simulation du contrôle du clavier avec 4+1 servo:
Pour faire fonctionner la simulation, il suffit d'envoyer une commande ainsi:
suivi de Enter. Le E en fin de code est pour le servo de la touche Enter.
Toutes les variantes avec les 4 chiffres du code (3478) sont possibles, si erreur, il y a un message:
Execution de: CODE4870E
Code a composer: 4870E
Code ???
Autres commandes;
CARTEIN Introduction de la carte
CARTEOUT Retrait de la carte
Une version avec solénoïdes:
Cordialement
jpbbricole
Le plus simple c’est de faire un serial print à la fin du setup pour dire que tout est prêt et ça fait apparaître le moniteur
Sinon il faut éditer le fichier de configuration pour rajouter un attribut au moniteur série (on peut alors aussi régler ce qui est envoyé comme fin de ligne )
"serialMonitor": {
"display": "always",
"newline": "crlf",
"convertEol": false
}
Toutes les infos détaillées sont ici
OK, Merci!
Cette proposition me parait la plus raisonnable.
J’ai une préférence pour un solénoïde qui représente le mieux l’action d’un doigts.
La course d’un solénoïde peut se régler, certains modèles ont un axe traversant.
Ce qui permet de les utiliser au choix en mode travail ou en mode repos.
Je pense qu'un servo peut tout aussi bien, même mieux "imiter" la pression d'un doigt?
Ce n’est qu’une impression personnelle.
C’est très subjectif que ce soit pour le choix solénoïde ou que ce soit pour le choix servo.
Le projet doit être pris dans son ensemble sans oublier la réalisation mécanique qui ne sera pas la partie la plus simple.
La phase de test sera longue et le matériel de test doit être fiable, et ça c’est de la responsabilité de @g_daniel .
D'autant plus que si j'ai bien compris, le systéme insertion carte + generation mécanique du code n'est en lui même que un outils pour tester le logiciel de paiment.
Donc il faudrait je pense, si c'est pour un vértable automate de test, que lui même soit fiable à 100% pour pouvoir certifier que tous les "insertion carte + saisie code" se sont passés sans défaut.
Les 5 (4+1) "doigts" que vous avez postionnés une fois pour toutes si j'ai bien compris, ne sont capable de faire qu'un seul code!
Lorsque nous avons réfléchi à cette solution avec solenoides, nous envisagions de pouvoir les déplacer en fonction du code de la carte si on venait à en changer. en imprimant une petite grille au dessus du TPE et sur laquelle on peut clipser les "doigts". Nous savons que c'est plus compliqué que ca malheureusement
Notre objectif n'est pas de tester le terminal de paiement mais de finaliser la vente du produit en réalisant le paiement au plus proche de la réalité. Sur une application web de poste bureautique, nous n'avons aucun soucis à utiliser des "bouchons" pour faire croire à l'application qu'on a payé. Sur tablette et compte tenu de la politique de sécurité des applications internes, nous n'avons pas la possibilité d'installer une application "bouchon" mais nous avons accès à tout le matériel permettant de payer. Comme c'est une application qui est en cours de développement et que le mode de paiement le plus courant est par carte bancaire, c'est la seule partie disponible pour l'instant. C'est un moyen de compléter le test qu'on doit réaliser.
Et quoi qu'il en soit, comment sur l'objet final le code passera "sans les mains" du cerveau au TPE.
Notre automate va réaliser des actions sur la tablette pour préparer la vente. Arrivé au moment du paiement, il va envoyer une instruction par API à notre serveur de pilotage des cartes controleurs (nous avons testé ca fonctionne avec le sans contact). On peut imaginer comme première INSERTCARTE, au serial print "OK", on passe a la saisie du code avec un "CODE1234", au serial print "OK", on valide le code "VALID". Lorsque toutes ces étapes sont faites, le TPE redonne la main à l'application pour le débit et donc à notre automate pour vérifier que le paiement se déroule bien. Dès lors que l'automate a détecté que le paiement s'est bien déroulé, une derniere commande est envoyée (RETRAITCARTE).
Déja qu'il faudra bien que les mains posent la CB sur la glissiére qui va l'insérer dans le TPE.
L'idée qu'on en a est celle décrit dans mon premier message. Une carte est dédiée à ces actions, on en changera qu'a l'expiration (3 ans). La carte est sur un support et l'insert est actionné par un servo moteur en linéaire ou un moteur pas a pas etc... Tout se fait à distance.
Notre prototype de paiement sans contact nous a permis de le démontrer.
Je suppose qu'il veut réaliser un petit automate qui va tester l'endurance de leur produit. Pour cela ils ont une carte de test avec un code connu et ils veulent sans doute tester l'insertion 100,000 fois et taper les codes corrects (et/ou faux ?) 100,000 fois pour voir si tout se passe bien.
Le fournisseur du TPE doit deja le faire
Indirectement ce sera le cas. Si on a 50 tests avec du paiement carte, il y aura évidemment 50 actions sur le TPE.
Mais ce n'est qu'un moyen de finaliser notre test. Quand on fait une vente, il faut aller jusqu'au paiement. L'avantage c'est que cela nous permettra d'aller plus loin comme par exemple vérifier les flux comptables qu'on ne peut pas faire si on bouchonne.
L'idée de la table me plait bien. Ca permet d'avoir qu'un "doigt" et de pouvoir gérer les boutons par coordonnées sans se poser de question sur le changement de code à l'avenir.
Merci beaucoup ! je n'en demandais pas tant
Je regarderais si on a quelques servo pour tester meme si on a pas la totalité
Je n'ai sincérement RIEN COMPRIS.
Vous me donnez un exemple qui est celui-ci:
Mais je ne vois pas votre systéme être utile dans cet exemple!
C'est pas grave.
Partons du principe que je suis un marchand de vetement.
La direction envisage de créer une flotte de tablettes avec une application de vente des produits du magasin. Au lieu d'aller jusqu'a la caisse pour régler, une cliente pourrait le faire directement en sortie de la cabine d'essayage par exemple. Surtout si une vendeuse/conseillère l'a accompagnée.
La cliente souhaite donc régler, elle en a pour 150€. La vendeuse va sortir sa tablette et commencer à sélectionner les différents articles et ensuite demander à la cliente de régler par carte bancaire. La vendeuse va lui tendre le terminal de paiement pour qu'elle puisse insérer la carte et taper son code puis retirer la carte et partir toute contente de ses achats et du temps gagné à ne pas faire la queue.
Mon boulot en tant que automaticien de test logiciel va être de tester un maximum de combinaison de vente sur l'application comme par exemple appliquer un code réduction, ajouter un produit puis le retirer pour s'assurer que cela fonctionne, tester le panier etc...
Mais surtout on va devoir aller au bas de la démarche en réglant les commandes. Notre projet c'est de faire un sorte qu'on puisse tout le temps régler par CB quelque soit le montant. On a besoin d'utiliser qu'une seule et unique carte. Notre besoin c'est que le paiement soit réalisé et on a qu'un moyen c'est d'automatiser par du robot les actions que ferait n'importe client lors d'un paiement : INSERT, CODE, VALID, RETRAIT