VM167 Driver Version

Good Morning

I have an issue where I have an Arduino Nano connected to another serial port on my PC.

When the program using the VM167 was working the Arduino application was frozen. We then disconnected the VM167 and the Arduino program came to life. The VM167 was then reconnected but the program failed as it could not see the port. Restarting the application allowed it to continue working but the Arduino program then locked up.

This leads to the conclusion that the devices are conflicting.

I have found that there is a newer signed driver (the old one wasn’t signed) for the VM167 interface card.

For some unknown reason, the new driver version shows and the old one yet is 2 years newer!

I have installed the new driver on one PC and it will be tested later today but would like to know the difference between the 2 versions? What changed? The PC is running build 1903 windows 10.

NEW Driver


OLD Driver


The drivers are from different vendors, this explains the “odd” version numbers.
The vendor of the old driver version (dated 19/12/2007) is Microchip.
The vendor of the new driver version (dated 24/08/2009) is Microsoft.
Only the new driver version works well with the new operating systems such as Windows 8 and 10.

Thanks for the info. Do you have any suggestions about what could be causing the application to hang?
There appears to be a conflict with the VM167 and the Arduino Nano

Hello dazza99,

Can You give Us more info how You use the Arduino Nano and VM167?

  • How are they connected to each other => we need circuit diagram and picture.
  • Which software are You using on VM167? included software or other?
  • Which sketch You’re using on Arduino Nano?
  • Did You tried other USB ports?
  • Did You tried on another “clean” PC?

With the info We have now, it’s difficult to investigate what the problem could be.

Best regards,
Velleman Support

I have a vb.net program using a VM167 with a single button connected. The .net code has been working for over 6 years with the VM167 with no issues.

I then needed another application (vb.net) to do another function on the same PC that also required I/O. This time a single switch and temperature probe.

I initially tried to use another VM167 but after problems and logging a call with Velleman support was told that it would not work as the 2 boards could not be addressed from separate applications.

I then turned my head to using an Arduino instead with a very basic sketch that sends a string to the serial port when either the switch is pressed or the temp changes.

The serial port receives commands ( for capture and for temp) and these are processed by the application. This has been working fine for about 18 months.

In the last few weeks the application that uses the Arduino has been locking up and the only thing that fixes it is to remove the Arduino and reconnect it. Further testing found that if I removed the VM167 from the PC, the Arduino application carried on working without the need to unplug the Arduino. This leads me to believe there is a possible conflict with the I/O ports.

The Arduino sketch is below…

String version = “v3”;

#include <OneWire.h>
#include <DallasTemperature.h>
#include <Bounce2.h>

#define ONE_WIRE_BUS 6 // Pin temp sensor is connected to

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);

int Celcius=0;
int lastTemp = 0; // Last known temp so we can see if it changed
int tempOffset = 2; // Only send the temp if has changed by ‘tempOffset’ degress value since ‘lastTemp’
const int BUTTON_PIN = 2; // Pin number of the rig switch
const int FAIL_PIN = 5; // Pin number of the PLC output for a failed image
const int PASS_PIN = 4; // Pin number of the PLC output for a passed image
const int LED_PIN = 13; // Pin number of the status LED
String data = “”; // For incoming serial string data

Bounce debouncer = Bounce(); // Instantiate a Bounce object

void setup(){
while (!Serial) ; // Wait for Arduino serial monitor to open
lastTemp = round(Celcius); // Store the current temp into lastTemp
Serial.println("Arduino_Interface_Connected " + version); // This string is looked for by the main program to ensure the interface exists. DO NOT CHANGE IT!

Serial.print("<T"); // Write the temp now as the program needs it at startup
debouncer.attach(BUTTON_PIN,INPUT_PULLUP); // Attach the debouncer to a pin with INPUT_PULLUP mode
debouncer.interval(25); // Use a debounce interval of 25 milliseconds
digitalWrite(PASS_PIN, LOW); // Initial state of output pin
digitalWrite(FAIL_PIN, LOW); // Initial state of output pin

void loop() {

void readInput() {
debouncer.update(); // Update the Bounce instance
if ( debouncer.fell() ) {
Serial.println(""); // Command is picked up by main program and causes a snapshot to be taken

void(* resetFunc) (void) = 0;

void getTemp() {
if (round(Celcius) == -127) { //If the temp is -127 (known error) then don’t write it out
//Do Nothing!

//If the temp is greater or less than the offset then write the value to the serial port
if (round(Celcius) == lastTemp + tempOffset || round(Celcius) == lastTemp - tempOffset) {
lastTemp = round(Celcius);

void getSerialData() {
//if (Serial.available()) {
// clear Serial input buffer
while (Serial.available() > 0){
// read the incoming string:
String data;
data = Serial.readString();
if (data == “temp?”) {
if (data == “?”) {
// if (data == “on”) {
// digitalWrite(LED_PIN, HIGH);
// }
// if (data == “off”) {
// digitalWrite(LED_PIN, LOW);
// }
if (data == “reset”) {
if (data == “pass”) {
digitalWrite(PASS_PIN, HIGH);
digitalWrite(PASS_PIN, LOW);
if (data == “fail”) {
digitalWrite(FAIL_PIN, HIGH);
digitalWrite(FAIL_PIN, LOW);