The latest version of our virtual keyboard wedge software 232key is now able to press additional keys (comma, semicolon, space) after entering the data received from the connected device:
[related_posts_by_tax]
232key virtual keyboard wedge software news, tutorials and application examples. 232key transforms data received via RS-232 (COM port) into keystrokes. It was developed to capture the weight from scales and balances, but can be used with many other weighing instruments as well as with bar code readers.
The latest version of our virtual keyboard wedge software 232key is now able to press additional keys (comma, semicolon, space) after entering the data received from the connected device:
[related_posts_by_tax]
Our free software 232key enables you to easily transfer the weight from your scale or balance to any application running on your PC (as simulated keystrokes). It contains a list of compatible devices that we are constantly expanding.
However, we cannot possibly test every scale or balance on the market. Using a practical example, this blog post will show you how to determine whether your balance is compatible with our software.
As of version 2018.1.0, the following requirements can be found on our 232key homepage (under “limitations”):
- Data sent by your device has to be in ASCII format.
- Your device has to send each line of data only once, not continuously (by pressing a key on the device or automatically).
These requirements may change in future version. We recommend that you always consult our 232key.com website first.
You’ll need your scale, of course. For this example we used an Excell FD130 scale which we found among our samples:
At the time of the writing of this post, this scale did not have a predefined device profile in 232key.
It’s a good idea to try to find or download the user manual for your scale. As you’ll see below, you’ll most likely need it.
Your scale must be equipped with an interface which can be connected to a COM port on your PC (or appears as a COM port when connected). The FD130 has a DB25F port:
We used a straight (1:1) DB25M to DE9F RS-232 cable with an FTDI US232R-10 converter plugged into a USB port on our PC:
Your scale will probably require a different cable. If you’re lucky, the user manual contains further information. We’ll address the topic of finding the right serial cable in an upcoming post (it can be quite complicated).
We used HTerm, which you can download here. Simply unzip the downloaded file and start HTerm.exe (no installation required). There are many other (free) terminal programs which you could also use.
Before using an unlisted device with 232key, it’s a good idea to get it to work with a terminal program. Just like 232key, a terminal program requires that you make a few settings before connecting to your scale:
Only one COM port was shown on PC (created when the FTDI converter was plugged in). If you have the choice between multiple ports, consult the Windows Device Manager to determine the correct one.
We found the following interface parameters in the user manual of our FD130 scale:
To determine the correct baud rate, we accessed the scale’s RS-232 configuration (we couldn’t have done this without the user manual):
After all settings were made, we pressed the “Connect” button in HTerm and immediately saw a lot of data coming from the scale:
The data contained a stability and net weight indication, a polarity sign, the weight and the unit, then a carriage return and finally a line feed character:
ST,NT,+ 0g\r\n
Setting “Newline at” to “LF” in HTerm made things a bit clearer:
Concerning the requirements mentioned above, we confirmed that the data was sent in ASCII format. However, the scale was continuously sending 4 values per second, which is not suitable for use with 232key as all these values would be typed (you could, however, use it with our Simple Data Logger application).
We again consulted the manual and found that the setting could be changed from “rnP 2 – continuous transmission” to “rnP 4 – press the ⏎ key to transmit”. As the description says, in this mode the user has to press the ⏎ key on the scale to send the weight to the connected PC (once).
Another mode suitable for use with 232key was “rnP 1 – stable transmission”. In this mode, the scale sent each (stable) weight once. This is often referred to as “auto print on stability”.
Your scale may or may not have several different transmission modes. Please refer to your manual for further information. Unfortunately, there are some scales which only support continuous transmission and are therefore not suitable for use with 232key (at this time).
Unfortunately, there can be many reasons. Please read our extensive troubleshooting section on 232key.com.
If the output in the terminal program contains no human readable data, you’ll have to fix this before trying to use the scale with 232key. As an example, setting the baud rate in HTerm to a wrong value (e.g. 4800) resulted in the following output (with “Show errors” selected):
If you’ve confirmed that all interface parameters in HTerm match those of your scale and still can’t read the output, the scale might not be sending data using the ASCII format. If no ASCII mode is available, it cannot be used with 232key.
Instead of sending only the weight as shown on the display, some scales send a lot of data to the connected PC. Below you can see the output when we set our scale to a ticket format meant to be used with a printer (“rnP 6”):
If the data sent by your scale contains numbers other than the weight, they will also be captured and typed by 232key. This is usually not what you want.
There are two ways you can try to fix this:
232key was designed to capture only one value in each line of data (usually the weight). However, for some applications you may want to capture multiple values from one line, e.g. the weight, date, time, alibi ID and scale ID:
This is only possible with 232key Pro, a different software which has its own website.
As we were able to read the output in HTerm and had fixed the continuous transmission issue, we proceeded to configure 232key for use with our Excell FD130 scale:We selected “generic measuring instrument” as the device and set the COM port and all interface parameters to the same values as in HTerm. As the terminator, we selected “LF”, the last character in each line of data sent by the scale (as seen above).
In the output tab, we instructed 232key to send an enter key after typing the weight (this is of course up to you and your application).
We then pressed the start button and switched to Word for testing purposes. By pressing the ⏎ key on the scale, the weight was typed by 232key:
Received data and captured/typed values could also be seen in the event log in 232key:
Please visit 232key.com to download our free software for scales and balances. Our website also contains an extensive documentation, FAQ and troubleshooting section.
Should you have any questions, please post them in our support forum. However, please keep in mind that the problem is not caused by 232key if you cannot see readable output in a terminal software.
We regularly publish blog posts with application examples. You can find all 232key posts here.
If a virtual keyboard wedge software like 232key is not what you need, please have a look at our other software. For data logging applications where you want to log the weight, time and date to a file, we recommend using Simple Data Logger.
Our software 232key was originally designed to make it as easy as possible to capture the weight sent by a scale or balance (and then transmit it to another application as simulated keystrokes). As most weighing instruments also include the unit and possibly other characters, 232key assumes that the first (decimal) number it encounters is the weight. If you also want to capture the date and time sent from a scale, this can lead to unwanted results.
Let’s look at a simple example first. Below you’ll see the data received from an Ohaus Scout STX scale configured to transmit only the net weight (as it appears in the event log in 232key):
Net: 302.4 g ? N<13><10>
The blue characters were captured by 232key using the “Ohaus” device profile. In this example, 232key managed to successfully capture the weight.
If we change the “Print Content” of the Ohaus STX scale so that it sends both the net and tare weight, the event log shows that 232key still captures both values:
Net: 302.4 g ? N<13><10> Tare: 7.9 g T<13><10>
To have them appear in separate columns in spreadsheet applications like Excel, OpenOffice Calc or Google Sheets, we can go the output tab and modify the end with settings as shown below:
Alternating the “TAB” with the “Enter” key every 2 value will produce the desired result (shown in Google Sheets):
Things get significantly more complicated if we configure the scale to also send the date and time. The event log now looks as follows:
11/17/2017 15:04:21<13><10> Net: 302.4 g N<13><10> Tare: 7.9 g T<13><10>
Using its default strategy of capturing the first number in each line, 232key only captures “11” and ignores the rest of the combined date/time line (as the backslash cannot be a part of a decimal number).
We can try to fix this by going to the device tab and setting the device to “Barcode alphanumeric extended” (available in the Plus version). This device appears in italics, which means that it is a “text” device instead of a “numeric” device. Note: Do not click the set defaults button after making this change.
As the scale is now sending three lines of data, we should also enter the number “3” in the end with settings in the output tab:
If we press the print button on the scale again, the event log will show that all data has been captured by 232key:
11/17/2017 15:09:51<13><10> Net: 302.2 g N<13><10> Tare: 7.9 g T<13><10>
The output in Google Sheets looks as follows:
If we simply wanted to record all data sent from the scale, this would be fine. However, it is not ideal for further processing for two reasons:
232key does not support extracting multiple values from one line of data, so there’s nothing we can do about the first issue (although you could use 232key Pro with a custom script instead). Unfortunately, our Ohaus Scout STX scale cannot send the date and time in separate lines.
The second issue can be fixed using custom regular expressions. To do this, go to the device tab, click on the customize button and replace the existing regular expression with the following one:
(\d{2}/\d{2}/\d{4}\s+\d{2}:\d{2}:\d{2}|-?\d*\.\d+)
Note: This regular expressions assumes the scale is using the 24 hour time format.
The event log and the output in the spreadsheet now look as follows:
15:38:40 11/17/2017 15:39:01<13><10> 15:38:40 Net: 302.2 g N<13><10> 15:38:40 Tare: 7.9 g T<13><10>
The cells containing the net and tare weights are recognized as numbers and can be used for further calculations.
If we just wanted to capture the time (and maybe add a “date” column manually), we could use the following regular expression:
(\d{2}:\d{2}:\d{2}|-?\d*\.\d+)
232key uses pre-defined regular expressions to match the data coming from the connected device and to capture the value you’re interested in. In this article, we’ll demonstrate the use of custom regular expressions (available in the paid Plus version) to capture the (net) weight from a balance and avoid capturing values we do not want to be typed. The instructions posted below can be applied to all kinds of serial devices (not only balances and scales).
For this example, we’ll be using an Adam Equipment HCB 3001 portable precision balance. It’s equipped with an RS-232 and USB interface. Either one works with 232key:
232key comes with a device profile for this balance. When you select it in the input tab and then press “Set defaults” to set the interface parameters, the following message appears:
This message asks you to modify the balance’s output format so that it only sends the (net) weight to the connected PC. If you change this setting, you won’t have to modify the regular expression in 232key as shown below. However, many other balances and scales have a fixed output format which cannot be modified (you can find multiple real-life example in our support forum). To simulate this problem, we’re keeping the balance set to output format 1 (default setting). As we’re about to see, this output format is not ideal for use with 232key.
In the output tab, we instruct 232key to press the enter key after typing the weight (clearly separating the captured values as they’re being typed):
If we now place an object on the balance, switch to an application like Notepad and press the print key, 232key types not just the weight, but 3 values, e.g.:
108.6
1
108.6
Weighing a second object leads to the following output:
83.0
2
191.6
A look at the event log in 232key reveals the problem with output format 1: The scale does not only send the weight over the interface, but also the number of accumulations and the total accumulated weight, each in a separate line. 232key captures and types all of these values (as it has no way of knowing which value you’re interested in). This is indicated by the characters in blue in the event log (note how they correspond to the output above):
To make sure that 232key only captures the weight from the first line and nothing else, we have to find out what makes this line unique. One candidate would be the unit (“g”), but unfortunately it also appears on the third line:
GS 108.6 g No. 01 Total. 108.6 g
However, only the first line starts with “GS” (which – according to the user manual – stands for “gross weight”). Therefore, we have to make sure that 232key only matches lines starting with “GS”. To do so, we go to the input tab and click on “Customize…”. This brings up a dialog which lets us modify the regular expression associated with this device:
The regular expression shown above captures the first (decimal) number it encounters. You don’t have to fully understand it, it’s sufficient to add “GS” in front of it to make sure 232key only matches lines where these characters appear before the desired value:
When weighing the same two objects again, 232key now only captures the weight from the data sent by the balance (as highlighted in blue in the event log):
In many cases, it’s really that easy to prevent 232key from capturing too many values. All you have to do is find out what makes the line containing the desired value(s) unique and modify the regular expression accordingly. However, as discussed below, sometimes things can get a bit more complicated.
The space characters sent by the balance after “GS” are currently being matched by the “\s*” expression inside the parentheses. (“\s*” means “match a whitespace character between zero and unlimited times”):
GS([-+]?\s*[0-9]*[\.,]?[0-9]+)
If the balance were to send a negative value, the fact that “\s*” appears after “[-+]” in the regular expression could become a problem. This depends on the position of the minus sign in the data sent by the balance:
If you encounter this kind of problem, add another “\s*” right after the characters you’ve added before:
The regular expression above instructs 232key to look for “GS” and white space characters (between zero and unlimited times) ahead of the weight (and ahead of a potential minus or plus sign). Do we need it for the Adam Highland balance used in this example? We can’t say, because unfortunately it refused to send (“print”) any negative weights at all. For the following examples, we’ll be reverting to our previous regular expression.
There’s something else we did not consider: Remember that “GS” stands for gross weight? What happens if we tare a container, place an object inside and then press the print key? 232key does not type anything! A look at the event log reveals that the scale sent “NT” for net weight instead of “GS”. As this does not match our regular expression, 232key ignores the entire line:
This can be fixed by using an alternation that matches either “GS” or “NT”:
However, testing this new expression shows that we’ve made things worse. Not only did 232key not type anything, the event log also contains several error messages:
We forgot to consider that 232key will always capture and process the data from the first capture group only. A capture group is marked by round parentheses and we’ve just inadvertently added a new one which captures either “GS” or “NT”. 232key then tried to convert these characters into a number, which obviously had to fail.
The solution is to mark it as a non-capturing group by adding “?:” as the first characters inside the parentheses. This means that the group is used for matching, but not for capturing data:
Testing this expression shows that 232key now works as expected and also captures the net weight:
This is just one example of how you can use custom regular expressions in 232key Plus. If you want to learn more about regular expressions, this Quick Start guide is a great place to get started. If you need help creating a custom regular expression for your device, please post your question in our support forum.
This article describes how you can capture the weight from a weighing instrument with differentiated digits using 232key Plus.
When looking at the display of an approved class I or class II weighing instrument, you might notice that one or more digits are visually differentiated from the others:
This is also called an “auxiliary indicating device” and is supposed to remind the user that on these instruments, the actual scale interval (d) is not the same as the verification scale interval (e). For the scale shown above, e is 0.1 g and d is 0.01 g. Since e is used to determine the maximum permissible error, we can consider the differentiated digit(s) to be less accurate (but that’s not the topic of this article).
Some scales do not only visually differentiate the last digit(s), they also use a separator when transmitting them to a PC (or a printer). Instead of receiving a string like “250.01”, the software running on the PC would receive something like “250.0/1” or “250.0[1]”.
When using our virtual keyboard wedge software 232key, this separating character prevents the weight value from being captured completely. Instead, 232key only captures “250.0” (highlighted in blue in 232key’s event log):
Fortunately, you can easily fix this in the Plus version of our software in just two steps (both are necessary).
Let’s continue using ‘/’ (slash) as a separator for this example. By default, most device profiles in 232key are meant to capture numbers and therefore 232key will stop capturing when it encounters the first non-numeric character. We have to change this behavior to make sure that 232key captures the digits preceding the separator, the separator itself and the following digit(s).
To do so, we first select the device profile we want to use (we’ll go with “Generic measurement instrument” in this example), and then click on the “Customize…” button to open the regular expression dialog:
The current regular expression captures the first number it encounters (which can be positive or negative and have a dot or comma as a decimal separator):
([-+]?\s*[0-9]*[\.,]?[0-9]+)
By expanding it as below we can instruct 232key to match a slash (‘/’) and the following digits, too:
([-+]?\s*[0-9]*[\.,]?[0-9]+/[0-9]+)
Depending on the selected device profile, the regular expression shown in the dialog might look different. What’s important is that it has to be expanded to include the separator and the differentiated digits.
Note: If the separator character used by your scale has a special significance in regular expressions, it must be preceded by a backslash ‘\’. Examples: Round and square “open bracket” characters ‘(‘ and ‘[‘. For the round bracket ‘(‘ as a separator character, the regex would be:
([-+]?\s*[0-9]*[\.,]?[0-9]+\([0-9]+)
Thanks to the modified regular expression, 232key is now able to capture the entire value transmitted from the scale, including the separator.
However, this will result in a number format error (java.lang.NumberFormatException) if a numeric device is selected in the input tab. If a text device is selected, the separator would be included in the characters typed by 232key. Both of these outcomes are undesirable.
Therefore, we have to instruct 232key to remove the separator from the captured data by going to the “Process” tab and entering it in the “Remove” text field:
Once this second step is completed, 232key will handle differentiated digits correctly: When the scale sends “250.0/1”, 232key types “250.01” into the target application (e.g. a spreadsheet):
Note that you may have to adapt these instructions to match the separator sent by your scale. As mentioned, you’ll also need a paid 232key Plus license to enable the functionality shown in this article. Please don’t hesitate to contact us should you need a trial license. For assistance, please post in our support forum.
232key version 2016.2.3 comes with the ability to ignore consecutive duplicates. This means that you can instruct 232key to ignore identical data captured several times in a row. I’ll explain this new feature with two usage examples.
Let’s say that you’ve set up 232key to capture the weight from a scale and type it into a parcel processing software running on a PC. To send the weight from the scale, the user presses the “Print” button on the scale’s indicator:
Everything works fine, except that sometimes the button is inadvertently pressed twice, generating two parcel labels. You can use 232key’s new feature to prevent this from happening by checking the “ignore consecutive duplicates” option:
The new ignore function will prevent the second weight from being typed. However, sometimes you might actually encounter two parcels with the same weight in a row. The second parcel would now be ignored by 232key. To fix this, click on the “Adjust…” button and enter a time limit (in milliseconds, e.g. “3000” for 3 seconds):
Any data received after the indicated time has passed is no longer ignored. Each new captured value resets the timer.
In auto print mode, a scale sends the weight automatically without requiring the user to press a button. Not all scales are equipped with this mode and not all auto print modes work in the same way. The Ohaus T31P indicator used in our example has a very simple auto-print mode: It sends every stable weight to the connected PC. This can cause issues if the weight of an item fluctuates between two values: The scale might send these values several times for as long as the item remains on the platform (e.g. 20.00 and 20.05 [kg]).
This is where the second setting in the “ignore consecutive duplicates” dialog comes into play: By defining a tolerance, 232key ignores a range of values. For our example, we’d enter a tolerance of ±0.05:
Now, when the scales sends a weight of 20.05 after just having sent 20.00, it is considered a duplicate and is not typed by 232key.
Our popular virtual keyboard wedge software 232key is about to receive a major update with significant user interface improvements as well as new functionality.
The first thing you’ll notice in the new version is that the tabs have been renamed and that a new tab has been added:
Input: This used to be the “Interface” tab. It lets you specify from where 232key receives its input, i.e. from which device connected to which interface. Eventually, this tab will also include an option to capture data using custom regular expressions (planned for version 1.7) and further interface options (TCP/IP and possibly USB HID in addition to RS-232/COM port).
Convert: Here, you can tell 232key to convert the data captured from the connected device. A new operation allows you to remove (or keep) the first (or last) x characters, which can be useful if your device sends additional data which you do not want to keep. The multiplication, division and rounding operations which used to appear in the “Format” tab can also be found here. All of these operations are optional, therefore you can ignore the entire tab if no conversion is required.
Output: This tab contains all settings related to the simulated keyboard (and sound) output (e.g. keyboard type, additional keys to be sent before or after the data). These are the settings from the “Format” tab which were not moved to the “Convert” tab.
We hope that the reorganized tabs make working with 232key easier even as we keep adding new features. We’re now going to run extensive tests to ensure that our software works as reliably as ever. We look forward to releasing 232key version 1.60 in the coming week.