Getting data from a digital caliper USB Keyboard

[lgc102]

How do I read data from a USB digital caliper that emulates a USB Keyboard?

The history: we have an industrial tester that uses 12" Starrett 797 calipers to measure position in 4 places as part of the test, and the tester uses RS232 to get the data. Program uses VISA Serial, asserting RTS/DTS to ask the caliper to send data via serial. One of the calipers died, and is no longer available - what was given us by Starrett as "equivalent" was a 798S with a smartcable that is USB, and emulates a USB Keyboard, which is NOT compatible with the existing software caliper interface. I have source code, and can rewrite, but haven't been able to alter the program to read data from the new caliper. 

After digging for a while (this and this were interesting but didn't help), I'm still stuck. 

Software and tester is a bit old (LV8.6). Company that made it is out of business.

[billko]

If you follow examples for bar code scanners that act like keyboards, I believe you will find the code you are looking for.

[lgc102]

---

@billko wrote:

If you follow examples for bar code scanners that act like keyboards, I believe you will find the code you are looking for.

---

Most common thing I find for that is to poll a string control, unless I'm missing something?

That's a really messy option here, the caliper is fully automatic (user never sees it or operates it and data is never displayed, used internally as a position encoder for the equipment). Unless perhaps there's a way to set keyfocus to a control on a vi without a front panel open?

[billko]

Use an event structure to grab the "keystrokes" as they come in and add it to a string constant.  This is very general because I don't really know exactly how the caliper works.  What do the "keystrokes" represent?  ASCII numbers?  Bytes?  DBL?

[lgc102]

---

@billko wrote:

Use an event structure to grab the "keystrokes" as they come in and add it to a string constant.  This is very general because I don't really know exactly how the caliper works.  What do the "keystrokes" represent?  ASCII numbers?  Bytes?  DBL?

---

Plug in caliper, open Excel, and the numbers pop in as ASCII numbers when you push the send button on the caliper. Useful generally. Not so useful here.

I'll try that, question first: how do I differentiate between keystrokes from the caliper and keystrokes from the user at a real keyboard who may be typing numbers at the same time?

[billko]

---

@lgc102 wrote:

---

@billko wrote:

Use an event structure to grab the "keystrokes" as they come in and add it to a string constant.  This is very general because I don't really know exactly how the caliper works.  What do the "keystrokes" represent?  ASCII numbers?  Bytes?  DBL?

---

Plug in caliper, open Excel, and the numbers pop in as ASCII numbers when you push the send button on the caliper. Useful generally. Not so useful here.

I'll try that, question first: how do I differentiate between keystrokes from the caliper and keystrokes from the user at a real keyboard who may be typing numbers at the same time?

---

That's a good question.  If you have several keyboards, as far as I know, all input gets directed to the application in focus.  In fact, I am using two different keyboards to type this response.

[Kyle97330]

It might simply be more practical to use eBay as a solution...

[lgc102]

---

@Kyle97330 wrote:

It might simply be more practical to use eBay as a solution...

---

Aye, it would be more practical, and we've been working on that end as well. Saw that eBay auction before I posted here. That's a 6", not the 12" I need. Haven't seen a 12" on ebay in the 2-3 weeks we've been wrestling with this. Also trying to work with Starrett to get it to be true RS232 (no luck yet), and finding another type of caliper that is RS232 (no luck yet). Still trying.

My hope was that the magical Font Of Remarkable User Methods (F.O.R.U.M.) would have a Labview side workaround, as we've been remarkably unsuccessful on the hardware side. 

[lgc102]

---

@billko wrote:

---

That's a good question.  If you have several keyboards, as far as I know, all input gets directed to the application in focus.  In fact, I am using two different keyboards to type this response.

---

Tried this method (event handler with Key Down?), got it to work more or less.

I set up a boolean to be in "caliper mode" where it intercepts all keystrokes then concatenates them until the CR is received a the end of the data, then converts to DBL.

Works as a standalone app, but tying this into the existing message-based architecture would be annoying - need to put the event handler in the Main GUI and add a bunch of new data infrastructure to pass the value around to all the subvis that need it. Feels kludgy. I need it to work in a low-level, non user facing subvi.

I looked into setting up a NI-VISA driver for it, forcing it into USB RAW mode, but got stuck as I didn't have the interface details for that. If I could query it with a NI-VISA call, it would tie effortlessly into the existing architecture.

[billko]

---

@lgc102 wrote:

---

@billko wrote:

---

That's a good question.  If you have several keyboards, as far as I know, all input gets directed to the application in focus.  In fact, I am using two different keyboards to type this response.

---

Tried this method (event handler with Key Down?), got it to work more or less.

I set up a boolean to be in "caliper mode" where it intercepts all keystrokes then concatenates them until the CR is received a the end of the data, then converts to DBL.

Works as a standalone app, but tying this into the existing message-based architecture would be annoying - need to put the event handler in the Main GUI and add a bunch of new data infrastructure to pass the value around to all the subvis that need it. Feels kludgy. I need it to work in a low-level, non user facing subvi.

I looked into setting up a NI-VISA driver for it, forcing it into USB RAW mode, but got stuck as I didn't have the interface details for that. If I could query it with a NI-VISA call, it would tie effortlessly into the existing architecture.

---

Can you somehow launch it async?  I know, it's getting uglier and uglier...