VM116/K8056 & Mingw32

hi.
i m under mingw32 / XP and i do not arrive to talk with vm116 (that works with demo software).

Led showing discussion stays muted…
I m suspecting an error in my way to talk to K8062D.DLL.
It returns me following infos on t:
Opening returns 2
and setchannelcount 33

Here is my code,any suggestion ?

yours,


extern "C" 
{
//VELLEMAN dmx K8062D
typedef int (CALLBACK * LP_VellemanStartDevice) (void);
typedef int (CALLBACK * LP_VellemanSetData)(int VellemanChannel, int VellemanData);
typedef int (CALLBACK * LP_VellemanSetChannelCount)(int VellemanCount);
typedef int (CALLBACK * LP_VellemanStopDevice)(void);
}


//pointeur vers velleman dmx
LP_VellemanStartDevice lp_VellemanStartDevice;
LP_VellemanSetData lp_VellemanSetData;
LP_VellemanSetChannelCount lp_VellemanSetChannelCount;
LP_VellemanStopDevice lp_VellemanStopDevice;
unsigned char DmxBlock[512];
int dmxvelleman_backup[512];

LoadingLib()
{
hLib = LoadLibrary("K8062D.dll");
 if (hLib == NULL)
 {     set_gfx_mode(GFX_TEXT,0,0,0,0);
     allegro_message("Impossible to load DLL\n%s\nFeednack HLib: %s\n", allegro_error,hLib);
  ; return(0);
 }
 lp_VellemanStartDevice = (LP_VellemanStartDevice) GetProcAddress(hLib, "StartDevice");
 if (lp_VellemanStartDevice == NULL)
 {   set_gfx_mode(GFX_TEXT,0,0,0,0);
     allegro_message("Impossible to open Velleman K8062D GetProcAdress\n%s\nFeedback: %d\n", allegro_error,lp_VellemanStartDevice );
 }
 lp_VellemanSetData = (LP_VellemanSetData) GetProcAddress(hLib, "SetData");
 if (lp_VellemanSetData == NULL)
 {   set_gfx_mode(GFX_TEXT,0,0,0,0);
     allegro_message("Impossible to open Velleman K8062D SetData GetProcAdress\n%s\nFeedback: %d\n", allegro_error,lp_VellemanSetData );
 }
 lp_VellemanSetChannelCount = (LP_VellemanSetChannelCount) GetProcAddress(hLib, "SetChannelCount");
 if (lp_VellemanSetChannelCount == NULL)
 {   set_gfx_mode(GFX_TEXT,0,0,0,0);
     allegro_message("Impossible to open Velleman K8062D SetChannelCount GetProcAdress\n%s\nFeedback: %d\n", allegro_error,lp_VellemanSetChannelCount );
 }
 
  lp_VellemanStopDevice = (LP_VellemanStopDevice) GetProcAddress(hLib, "StopDevice");
 if (lp_VellemanStopDevice == NULL)
 {   set_gfx_mode(GFX_TEXT,0,0,0,0);
     allegro_message("Impossible to close Velleman K8062D  GetProcAdress\n%s\nFeedback: %d\n", allegro_error,lp_VellemanStopDevice );
 }
return(0);
}

int OpenInterface()
{
  if (lp_VellemanStartDevice != NULL)
 	     { 
 	 	     int iRet = lp_VellemanStartDevice(); 
 	 	     if (iRet != 1)
    		 {
              set_gfx_mode(GFX_TEXT,0,0,0,0);
              allegro_message("Impossible to open interface, is it PLUGGED ?\n%s\nFeedback : %d\n", allegro_error, iRet);
              QuitMidi();return(0);
      	     }
      	}
    if (lp_VellemanSetChannelCount != NULL)
 	     { 
 	 	     int iRet = lp_VellemanSetChannelCount(512); 
 	 	     if (iRet != 1)
    		 {
              set_gfx_mode(GFX_TEXT,0,0,0,0);
              allegro_message("Impossible to set max chan to interface\n%s\nFeedback : %d\n", allegro_error, iRet);
              QuitMidi();return(0);
      	     }
      	} 
return(0);
}

int CloseInterface()
{
 if (lp_VellemanStopDevice != NULL)
         { 
              lp_VellemanStopDevice(); 
         }
return(0);
}


int DmxVelleman_SendData()
{  
for(int ixx=0;ixx<512;ixx++)
    {
    if((int)DmxBlock[ixx]!=dmxvelleman_backup[ixx])
    {
    lp_VellemanSetData(ixx,(int)DmxBlock[ixx]);  
    dmxvelleman_backup[ixx]=(int)DmxBlock[ixx];
    }
    }
 return(0);   
}

None of the K8062 functions have a return value

extern "C"
{
    typedef void (CALLBACK *LP_VellemanStartDevice)(void);
    typedef void (CALLBACK *LP_VellemanSetData)(int iChannel, int lpData);
    typedef void (CALLBACK *LP_VellemanSetChannelCount)(int cChannels);
    typedef void (CALLBACK *LP_VellemanStopDevice)(void);
}

yeap… discovered it after the post.

discovered also i was obliged to have k8062e.exe around the dll and my exe.

is there any possibility to have source code of this exe ?
communication with the device thruth it TOO SLOW for a serious dmx usage.

its like an old very old LPT communication speed… in worth…
or maybe my way to talk to it could be wrong ? i m open to any suggestions.

i am this free project: karistouf.free.fr/schwartzpeter_engl.html

You get it working much faster by reducing the SetChannelCount from 512 to the number you really need.
Arrange all your light fixtures to the low end of the channel (address) range.

sorry, but having less than 24 adresses to have smooth non-scalling transitions is not affordable.

i m using visible bulbs, my dimmers are ok, and i can make comparison with many interfaces…

that s why i m asking if there is no other way to access to this hardware.

i m so astonished by this rate to communicate with interface that i m deeply asking myself is there is no other way to do it, or if in its design people using it should be consider it as somehow only a kind of evoluate on/off.

does this hardware is really that bad ? ( velleman’s spirit where are you ?)

i would be pleased to discover i m making an ugly error. really…

Hi

I agree with karistouf. Just got it delivered. Realised that the k8062d.dll uses the k8062e application for sending
via USB. The k8062e application flashes on my scren everytime the dll is called. Not pretty!
Its slow and unreliable.

I want to rewrite this. Can i have sourcecode to dll and k8062e?

You can download the source from: vel255.diinoweb.com/files/K8062_DLL_source.zip

karistouf or steffe, have you sorted it out yet?

I have this interface (using it with FreeStyler) and noticed the delay also.
Somehow I got a delay of more than 500msec(!) under some circumstances, I checked the output from FreeStyler (made an K8062d intercept DLL myself, to make sure that FreeStyler doesn’t have the delay and it doesnt…)

So, it leaves one option, de K8062D.dll or K8062E.exe application is slow, or the interface itself is slow.
I guess the .exe is the key thing here.
I’m wondering if there’s something to do about it.

If possible I would like to have the source code of the K8062E.exe also, maybe we/I can rewrite the damn thing to speed things up. Or even write a K8062D.dll that does not need an external exe at all anymore.
Or (and maybe thats a better option) someone tells us how we can talk to the interface directly.

@VEL255:
That source code is not for the K8062E.exe but is an example on how to use the K8062D.dll
We are way past that bus stop. :wink:

Strange delays…
Hope you find a solution.
There in the ZIP package is both the demo software and the K8062e.exe and K8062d.dll source codes.

K8062e.dpr, Unit1.pas and Unit1.dfm for the K8062e.exe
K8062d.dpr and K8062dm.pas for the K8062D.DLL

[quote=“VEL255”]Strange delays…
Hope you find a solution.
There in the ZIP package is both the demo software and the K8062e.exe and K8062d.dll source codes.

K8062e.dpr, Unit1.pas and Unit1.dfm for the K8062e.exe
K8062d.dpr and K8062dm.pas for the K8062D.DLL[/quote]
That sounds good.
Where did you mean the Zip package is?
I looked around on the CD that came with the interface, did’nt found it.

Maybe its possible you put the zip temporary online somewhere?

Indeed, it is online.
You may download it from: vel255.diinoweb.com/files/K8062_DLL_source.zip

[quote=“VEL255”]Indeed, it is online.
You may download it from: vel255.diinoweb.com/files/K8062_DLL_source.zip[/quote]
Forgive me for my blindness. :frowning:
Had downloaded the zip already and thought it was only the example of how to use the DLL.
Thx.

I Found out why many peoply find this VM116 / K8062 to slow.

Recently, I rewrote the driver myself with a little help of the source code from posts above.
I planned to replace the K8062D.dll and K8062E.exe into one good working .dll
I managed to do that, but it does not make any difference in speed.
So I digged something deeper, I noticed earlier that the original velleman source code for the K8062E.exe was grouping all following 0-values together and send them at once to the interface, telling it to send XX 0-values.
First I thought, hell, why should they? Why not send every channel on its own?
While testing that, I found the most disturbing point. If sending all DMX channel on its own (per channel), then it takes more than 600 msec to write the data to the Velleman interface. Meaning that one light jockey has a delay of minimal 600 msec!

Then it suddenly becomes clear to me; they grouped all following 0 valued channels toghether because they have to send much much less data to the interface, speeding things up when lots of DMX channel values are 0.

So I tried the other way, using the original Velleman K8062D.dll and K8062E.exe.
When I send 512 DMX channels with a value 0 then a flash of a light reacts immediately.
Then I set 511 DMX channels to some value higher than zero*, and try to flash the same light again… Now it goes on with a delay of minimum 600msec. :frowning:
Pressing the flash button the wrong moment doubles that time to 1.2 seconds.

So the solution is to keep all DMX values to 0, then this interface is fast like hell. :laughing:
However, in practice thats not really an option. Imagine having 10 moving heads, each consuming 22 DMX channels.
All channels need to be set to some value. Then we have already 220 DMX channels with another value of 0. Now flashing a light has a delay more than 300 msec. Its so unusable in medium or larger DMX universes.

The problem is not the original Velleman driver, I tested that. So the only conclusion is that the interface is just to slow to receive all DMX data on its USB port.
And thats kind of strange, knowing that its not that much data thats gets to be sended.
The DMX protocol itself runs at about 250kbps, USB 2.0 ports can easily keep that up. But the pic in the Velleman interface obviously can’t manage that.
I assume that there is no easy fix for that, so I terminated my experiment and going to sell the interface and buy a better one.
Unless someone points me to something I overlooked the past few days…
Or maybe there’s a firmware fix available for the pic? (I think the problem is there…)

Ofcourse I did the same tests with ChannelCount(256) and lower number. All having the same ugly result: when there are many DMX values other than zero, it all gets slower and slower. In fact it is predictable:
Channel count 512, 512 DMX channels value >0: >600msec
Channel count 512, 256 DMX channels value >0: >300msec
Channel count 512, 128 DMX channels value >0: >150msec
Channel count 512, 64 DMX channels value >0: >75msec
Channel count 256, 256 DMX channels value >0: >300msec
Channel count 256, 128 DMX channels value >0: >150msec
Channel count 256, 64 DMX channels value >0: >75msec
… and so on…

  • When doing this, the DMX led on the interface flashes a lot slower than before…

Hi everyone!

I know this is an old thread, but hopefully someone can help.

Warning, totally noob questions and problem coming up!

At first i’d like to say that i’m new to DMX512 in general. I bought and assembled a vm116/k8062, it is built with the newer chip.(I would like to mention, that Maplin’s website had no indication whatsoever that this is a self-assembly kit so you could imagine my surprise) Currently i’m at the stage of trying to test if it works, but i seem to be stuck. Either i did something wrong and no signal is getting out, or the wrong commands are going out. Right now i have a zero88 AlphaPack with a par64 hooked to channel one connected to the interface. Stand alone test mode has no effect, neither does the test software.

The computer recognises the device, the “power” LED is continuously on, while the “DMX” LED is flashing.

How should i test it/what should i do to indetify what i’m doing wrong? I also have a bunch of Pulse LEDPar56s, and some LEDj pixel bars available if you think that’s easier to test, i assumed that the “dumbest” would be best.

Thank you in advance for your help!

So you bought a K8062. Velleman products starting with a K are always Kits. For those who want to build themselves.
The VM116 is the same, but its ready for use. No need to build it yourself.

Stand alone mode of what? The AlphaPack?
What test software? Vellemans test software itself, or something else?

You should make sure a DMX signal is coming out of the K8062. Probably you don’t have DMX analyzing tools, so you need to connect some DMX fixture/equipment that has a small DMX led on it to indicate it recognizes DMX signal, regardless of its address.
Maybe the AlphaPack or your LED par’s have something like that. Often they do and more often the DMX LED immediately lits up (or flashes) after powering on and DMX is connected and running.
If it does lit up: congratulations, your K8062 device seems to be working perfectly.
If it does not, the fixture doesn’t receive any usable DMX signal. Could be bad cabling, could be a failing K8062 kit.

Or, you could try and create your own (very, very, ultra) simple DMX tester:
bigclive.com/dmxtest.htm
Don’t be fooled if it lits up, there’s no guarantee you are actually sending a good DMX signal. Chances are pretty good, you are. But it might not be.
If it does not lit up, theres something wrong for sure. You are definately not sending DMX signal.

Also

  • Check possible 3 to 5 pin XLR adapters. Some people simply fail to create a good converter.
  • Check DMX polarity
  • Check cabling
  • Try and find a working DMX transmitter to rule out the possibility something else, besides the K8062, is wrong

[quote]The computer recognises the device, the “power” LED is continuously on, while the “DMX” LED is flashing.[/quote] If this is the case when you are running the test software, it seems the microcontroller of the K8062 is working properly.
The problem may be in the DMX interface section.
Solder failure, or connector or wiring problem.

Please check these threads for some cases:
viewtopic.php?f=3&t=4167
viewtopic.php?f=15&t=2392
viewtopic.php?f=3&t=6365
viewtopic.php?f=3&t=3537