2009-12-24 9 views
5

J'ai une application extrêmement simple fonctionnant à partir d'une série de scanners obsolètes qui ramasse un balayage de code barres d'un port série et renvoie au scanner un ok qu'il a reçu le balayage. Sur cette base, le scanner clignote en vert et l'utilisateur sait qu'il peut continuer. J'aime ce modèle sur ma compréhension d'un coin du clavier, car si quelque chose arrive à l'application ramasser le scan (l'application se bloque, le formulaire avec le focus est changé, le PC se bloque, le PC ne peut pas suivre ramasser les balayages), la personne qui tient le pistolet de balayage saura qu'il y a un problème parce qu'ils ne recevront pas le flash vert et ils ne pourront pas continuer la numérisation.L'utilisation d'un lecteur de codes-barres comme coin de clavier implique-t-elle que vous ne pouvez pas confirmer la réception de la numérisation?

Je cherche à ajouter quelques scanners et il semble que beaucoup de gens utilisent des scanners de codes à barres qui agissent comme des coins de clavier. Certains de ces scanners ont une portée supérieure à 100 pieds, ce qui implique que les gens les utilisent loin du PC (comme le sont mes utilisateurs). Je me demande donc s'il me manque quelque chose concernant le modèle de coin du clavier. Y a-t-il un mécanisme qui me manque pour m'assurer qu'une numérisation décodée par un scanner jouant le rôle d'un coin de clavier atteint effectivement l'application exécutée sur le PC? Un ordinateur de poche complet exécutant quelque chose comme Windows Mobile semble être trop lourd pour que mon utilisateur ne scanne pas les données qui ne vont pas dans l'application, et même un scanner de milieu de gamme avec un clavier et un écran , mais ce dernier est le point d'entrée pour toute sorte de programmabilité du scanner?

Répondre

5

Vous avez raison: il n'y a pas de boucle de rétroaction vers le scanner lorsqu'il fonctionne en tant que coin. Nous utilisons beaucoup les scanners à coins, et dans un environnement moderne (par exemple, Windows, plusieurs applications, etc.), la mise au point, les balayages abandonnés, etc., sont tous de vrais problèmes.

Nous sommes en train de changer de manière différente. Si vous avez le choix du matériel, de nombreux nouveaux lecteurs de codes à barres USB peuvent fonctionner en mode d'émulation en série, ce qui vous permet d'éviter le second balayage tant que l'hôte n'a pas reçu le premier, ou vous pouvez émettre un bip/faire clignoter quelque chose sur le scanner en tant que ACK). De plus, il existe un mode USB HID POS (point de vente) supporté par certains scanners USB haut de gamme qui vous offre une plus grande flexibilité, avec en prime l'installation "sans pilote" (cela ressemble à un périphérique HID générique le système, comme un joystick ou un clavier, mais avec une capacité de communication bidirectionnelle). L'inconvénient du mode POS est qu'il est un peu plus difficile que la programmation série, mais il existe des couches d'abstraction disponibles pour différentes plates-formes.

1

Les ordinateurs portables RF avec des scanners intégrés, comme le Symbol MC9090-G, sont de loin les plus flexibles et les plus utilisés. En ce qui concerne les coins, en fonction de la distance entre l'ordinateur et l'environnement d'usine - nous avons utilisé un retour visuel via l'écran du PC et l'audio via les haut-parleurs du PC. Les utilisateurs écoutent les commentaires audio après chaque analyse et quand ils ne l'entendent pas, ils retournent à l'écran du PC pour avoir un retour visuel sur le problème. Pas parfait mais ça a bien marché.