Enttec DMX USB Pro no output with 4.12.1 under Windows

[Addy90]

Hi there,

so when I updated from 4.12.0 to 4.12.1 my Enttec DMX USB Pro did not output anything anymore. When I change any DMX channel, no output is sent to the device, no LED on the device is blinking.
I have Windows 10 1809 and when I reverted back to 4.12.0 it worked immediately again! I tried to install 4.12.1 again, and it did not work anymore, 4.12.0 again and it worked again.
In any case, the DMX PRO MANAGER from Enttec itself always works. QLC+ also recognizes the device with input and output, also shows the serial number valid, but no output is sent.
I did disable the VCP mode, tried everything with driver uninstalling and reinstalling, but it did not help.
Some bug must have been introduced with 4.12.1 so that the DMX USB Pro device does not output anymore under Windows.

Can you fix this? Is there anything else I can supply for helping?

Thank you!

[mcallegari]

PRO devices haven't been touched from 4.12.0 to 4.12.1.
Must be something else. Is 4.11.2 working for you?

[Addy90]

Thank you for your fast response!
Okay I uninstalled 4.12.0 and tried 4.11.2 and it worked! Then I uninstalled 4.11.2 and tried 4.12.1 again: It did not work (as expected). Then I uninstalled 4.12.1 and installed 4.12.0 again and it worked (as expected).
Maybe the problem is not within the PRO code but in some other code around addressing the DMX output?

I was able to set up a build environment on my Windows 1809 computer having the problem. What I could try is doing a "binary search" within the commits from 4.12.0 to 4.12.1 to track down the commit and maybe the code that introduced the problem. I will add another reply when I have results. It looks like this is quite difficult to find when you cannot reproduce the problem...

[Addy90]

Dear Massimo,

I found the change that introduced the problem:
https://github.com/mcallegari/qlcplus/c ... fc24c1bfa4

When I changed that line for example to

Code: Select all

FT_SetTimeouts(m_handle, 500, 100);

The current build with 4.12.1 worked with only this change!

I saw, that the original API description has as example 5000, 1000 set: https://www.ftdichip.com/Support/Knowle ... meouts.htm
So it looks like the timeout of 1 millisecond is way too small for Windows to output anything anymore to a DMXUSB device.

What was your intention for that small timeout? Could it be possible to raise it to the values I suggested or even to the values from the API docs?

Thank you!

[mcallegari]

Thanks for investigating!
This is actually interesting.
I added that line to force stupid Windows to flush data to the serial line as soon as possible (default timeouts are longer)
As you probbaly know, serial drivers have in/out buffers (you can even configure their size in the driver properties dialog). Windows, and most likely macOS too, attempt to fill those buffers before actually sending data to the line. Otherwise, they work by timeout. For example if you write 10 bytes and buffer is 1024 bytes, timout has to expire for that data to be sent on the line.
Hope the explanation is clear.

To be honest I thought PRO devices weren't affected by this change, since they usually are buffered devices. I added that line for Open DMX devices, where I need precise timings from the software.
I'll build a new DLL also for this thread.

[Addy90]

Thank you for your quick response!

I understand the difficulty with the buffers (for example, I have seen this: https://www.ftdichip.com/Support/Knowle ... ataend.htm)...
What I also have seen is that DMX with a refresh rate of 44 Hz for 512 channels needs about 23 ms to be sent (see https://en.wikipedia.org/wiki/DMX512#Timing). I am not deep enough into the DMX protocol, but if this is true, which seems to be the case after http://www.dmx512-online.com/dmx512_packet.html, then maybe the write timeout of 1 ms did not have the intention of flushing the data but capping the data after 1 ms was ago. I have seen that for reading, there is a different command which does what you expected of the write command: https://www.ftdichip.com/Support/Knowle ... ytimer.htm. But there is no command for writing like this.

Moreover, I have seen after https://www.ftdichip.com/Support/Knowle ... meouts.htm that maybe, USB serial devices do not buffer by driver settings by default but only when you explicitly set it. So a timeout or flush might not be needed in this special case of USB serial devices?

If there is no "flush" command like with typical IO operations for writing on DMX, maybe the normal write operations are sufficient because the device listens for stop bits or "end codes".
For example, in the official DMX USB Pro example (from here https://www.enttec.com/products/control ... rface-dmx/), the following code is used for writing:

Code: Select all

int FTDI_SendData(int label, unsigned char *data, int length)
{
	unsigned char end_code = DMX_END_CODE;
	FT_STATUS res = 0;
	DWORD bytes_to_write = length;
	DWORD bytes_written = 0;
	HANDLE event = NULL;
	int size=0;
	// Form Packet Header
	unsigned char header[DMX_HEADER_LENGTH];
	header[0] = DMX_START_CODE;
	header[1] = label;
	header[2] = length & OFFSET;
	header[3] = length >> BYTE_LENGTH;
	// Write The Header
	res = FT_Write(	device_handle,(unsigned char *)header,DMX_HEADER_LENGTH,&bytes_written);
	if (bytes_written != DMX_HEADER_LENGTH) return  NO_RESPONSE;
	// Write The Data
	res = FT_Write(	device_handle,(unsigned char *)data,length,&bytes_written);
	if (bytes_written != length) return  NO_RESPONSE;
	// Write End Code
	res = FT_Write(	device_handle,(unsigned char *)&end_code,ONE_BYTE,&bytes_written);
	if (bytes_written != ONE_BYTE) return  NO_RESPONSE;
	if (res == FT_OK)
		return TRUE;
	else
		return FALSE; 
}

Looks like a flush is not necessary.

Moreover, the FT_SetTimeouts function is set with the following values:

Code: Select all

	int RTimeout =120;
	int WTimeout =100;
	// SET Default Read & Write Timeouts (in micro sec ~ 100)
	FT_SetTimeouts(device_handle,RTimeout,WTimeout);

When I look at the Open DMX example (from here https://www.enttec.com/products/control ... rface-dmx/), the following code is used:

Code: Select all

void __fastcall TDmxSender::Execute()
{
    int i;
    ULONG bytesWritten;

     // set RS485 for sendin
    FT_W32_EscapeCommFunction(ftHandle,CLRRTS);

    while (!Terminated) {

        FT_W32_SetCommBreak(ftHandle);
        FT_W32_ClearCommBreak(ftHandle);


        FT_W32_WriteFile(ftHandle, &StartCode, 1, &bytesWritten, NULL);
        FT_W32_WriteFile(ftHandle, DMXData, 512, &bytesWritten, NULL);
      
        Sleep(inter_frame_delay);
        NbFramesSent++;
    }
    

}

It looks different, no "end code" seems to be written. Maybe the Open DMX USB device indeed is "slower" in sending out commands than the PRO interface that maybe flushed when receiving the end code? I am just thinking about this... Because you said that you added the timeout for the Open DMX devices as they (obviously) do not flush but work on timing. Yeah, this was already clear to you, but for me it starts to make sense now, too ^^

Moreover, the timeouts are set as below:

Code: Select all

    FTTIMEOUTS ftTS;
    ftTS.ReadIntervalTimeout = 0;
    ftTS.ReadTotalTimeoutMultiplier = 0;
    ftTS.ReadTotalTimeoutConstant = 1000;
    ftTS.WriteTotalTimeoutMultiplier = 0;
    ftTS.WriteTotalTimeoutConstant = 200;
    FT_W32_SetCommTimeouts(ftHandle,&ftTS);

As this is a different timeout command, I am quite unsure what is the right way to do this for all operating systems (because it says W32). But it looks like 1 ms definitely is too low / has not the intended effect...

Maybe it is necessary to set the timeout with a higher value only for the Open DMX devices but not for the PRO devices... but instead send the end code with pro devices... and inform the user that if he/she needs very precise reacting DMX, the Open DMX devices are not sufficient for this. Just thinking again

Nevertheless: Thank you for helping with this!

[Dayoung24]

I have experienced a similar issue. With QLC+ v4.12.1 installed on my Windows 10 laptop the DMX output to my DMXKing UltraDMX Micro would stop whenever I adjusted my speed dial control to anything but 0. If the speed dial control was set to 0 DMX output would resume. I have back leveled to v4.12.0 and the issue no longer occurs.

[nedmech]

Just tried updating to 4.12.1 tonight and had the same issue as the original poster.

Windows 10 Pro, build 17134
DMXKing utralDMX Micro (firmware 1.2)

4.12.0 and 4.11.2 work, but 4.12.1 generates no output on the ultraDMX Micro. I had to uninstall 4.12.1 and re-install the earlier version to get it to work again. Just installing the older version over the newer one didn't fix anything. Something must have been getting left behind from the 4.12.1 version when I reinstalled 4.12.0 over it that required me to fully uninstall it first.

Hope this helps some. Looking forward to the next release. Thanks for all your hard work, Massimo!

[mcallegari]

Hi, please check the latest post of this thread
viewtopic.php?f=24&t=12867&start=20#p55939

DLL in dmxusb-20190311.zip should fix the issue. Please give it a go and report.

[nedmech]

Tested.

Started with 4.12.0 - everything works fine.
Installed 4.12.1 - Got DMX activity indication on one of my fixtures for a second when QLC first started, then nothing.
Exited QLC.
Copied dll from dmxusb-20190311.zip into plugins folder.
Relaunched QLC 4.12.1 and everything is happy again.

The new DLL fixes the problem for my machine. Thanks Massimo! I'll hold off on using 4.12.1 for my production machines though until there's a new version with the fix in it. I can manually patch my own machine easily enough, but I'd prefer to use complete installs of working versions for my production machines at my venue.

Thanks again! Keep up the great work!

[mcallegari]

Thanks for testing Nathan

[Addy90]

Dear Massimo,

I can confirm, too, that your dll from the other thread is working as expected with 4.12.1!
All lights working, output fluid.

Thank you a lot for your work!

[markzvo]

Also confirming that replacing the DLL fixed my Enttec DMX PRO USB

[mcallegari]

Also confirming that replacing the DLL fixed my Enttec DMX PRO USB

What about 4.12.2? Should work out of the box

[markzvo]

Will test once the Pi image for 4.12.2 is released ... most of my work is edited on Windows and played from the Pi ... so I like to run the same version everywhere (I don't plan on a Pi 4 for QLC+ any time soon unless a Pi 4 w/QLC+ gives me something extraordinary).

Also, I did not realize there was a new version because usually the latest release is posted on the main webpage (www.qlcplus.org), but I found it in the announcements thread.

Very exciting news - thank you for the hard work. Will test soon.