Epson xdd Not Working - Thread<workerThread>not found
MarkJervis Posts: 5
edited February 16 in NetLinx Modules & Duet Modules
I am returning to AMX from a long hiatus and am trying to use an Epson xdd file. I have it loaded and it shows up in my tree but it doesn't work. When I run it in Debug I get "Thread<workerThread>not found: setPower(ON)" when trying to control power on, same for off.
Can anyone shed some light on this? What am I missing?
For reference, it is the Epson_Video_Projector_EB-PU1007W_PU1007B_1.0.0.
Mark, with XDD drivers, there is a third parameter required in the module definition statement. Do you see it in the documentation as an example? Does your code have this?
Reason - the xdd duet module is the same for every xdd type module. At run-time, it looks to the 3rd parameter which is essentially the xml that contains info on the device type and commands.
I have the following in my code:
Great - thank you for confirming. What is the controller, and what is your firmware?
DVX-3266-4K. Switcher is 2.0.0, Controller 1.1.50, Master 1.8.120
Mark, I was unable to find any additional information related to this. The 1.8 branch of firmware is currently localized to the DVX-4k line of products. I checked with a support colleague who was unaware of any issues with XDD on the 1.8 branch, but they would like you to open a ticket so they can replicate the problem and assist in solving it.
Just tell me what you need from me.
Call into support +1 844-776-4899
Email: [email protected]
I'm having the exact same issue, on firmware 4.1.430 on an NI-3100 and 1.6.189 on an NX-1200. I think I was able to work around it by importing the xdd into Driver Design and changing the serial communication from Epson to Custom with Footer checked for the command with the footer being 0D hex, and a regex footer of \x0d?: for the response. I can't actually test the changes for real until Friday afternoon, but this change got my test system to actually start sending data to the serial port, and parsing the responses from the projector.
Thank you. I will try that. I emailed TechSupport and they said they don't support the modules.
Mark - point of clarification on AMX Tech Support "said they don't support the modules."
1) XDD modules are two part - device driver and control protocol.
-The device driver is the same for all XDD drivers. If there is a problem, AMX will support the engine but it is old enough now to where it would be a bit surprising to find an edge case that is breaking it.
-Each driver should provide a SUPPORT email address for the developer who made it. Often, this is an employee at the manufacturer of the device.
2) Traditional AMX Duet modules are supported by AMX. In cases where a 3rd party wrote it, but we host it, we still facilitate bug reporting and will project manage the issue through to completion/resolution. In cases where AMX ITG writes the driver, we manage the remediation process in house. AMX Technical Support will create a support ticket, escallate it and assign it to AMX ITG for action. Things happen behind the scenes to test, recreate, and remediate - and then the ticket is updated and a resolution is passed on to the individual who reported the issue to test and validate the fix. Once validated, the update is posted to InConcert.
In your case, if you have validated with AMX Technical Support that the device driver is properly implemented, but an issue remains, the next step would be to contact the author of the protocol details. Your XDD download contains the interface doc which lists the author as [email protected]
I had the same issue with the Epson_Video_Projector_EB-PU2220B_1.0.0.xdd. I tried mstocum's workaround, and got it to work, also my customer on site confirmed that the RS232 communication works, as he is possible to do some basic functions by channel (power on, off, Pic mute, and also power feedback).
Comparing the original xdd with my modified file, I see that the original file has 9300bytes size, and my modified one has 9653Bytes, though I only changed the serial comm parameters from Epson to custom, with the same parameters. Maybe the original file was done by an older version of DriverDesign...
Just a note in regards to use it on a NI controller: In my customer's system, the driver has to be used twice. We found that the default Duet Mem of 12M was not enough to launch both instances. We set the Duet mem to 20M, then worked fine.