Jump to content
Sign in to follow this  
NBJ

FTD2xx.dll UDF

Recommended Posts

NBJ

Hi,

I have been working on a UDF for the Enttec DMX USB PRO (www.enttec.com) USB to DMX Dongle.

The Device has a FTDI chip from http://www.ftdichip.com.

I was having brain implosions while getting my head around all the dll calls and dllstructcreate issues so I went back to basics and decided to write a UDF for the FTDI's FTD2xx.dll

Which may be useful to others here, and helped me learn what the dll was requesting.

As the UDF is about 2000 lines I have added it as an attachment.

I have also included an example file.

I have uploaded here rather than in example scripts in an effort to get some assistance as to the correctness of what I have done.

This is my first real exploration of dll calls and dllstructcreate which means there are probably some errors in the UDF, if you see any please let me know.

I have tried to stay as close to the FTDI documentation as possible. see http://www.ftdichip.com/FTDrivers.htm

If anyone has some comments on how I can make this better, please let me know.

Here is the UDF header so you can see what functions there are

;=================================================================================================
; FTD2XX.dll_UDF for use with the FTD2xx.dll
;=================================================================================================
; AutoIt Version:   3.3.0
; Language:         English
; Platform:         Win2K+
; Author:           Neil Jensen (wakido;NBJ)
;=================================================================================================
; Requirements:     FTD2XX.dll (http://www.ftdichip.com/FTDrivers.htm)
;                   An FTD2XX Device for FT and USB functions
;                   Any Modifications are posted on the AutoIt Forums
;=================================================================================================
; Credits:          All of the AutoIT Community on the AutoIt Forums
;                   brunomusw  & DanP2 in the topic [url="http://www.autoitscript.com/forum/index.php?showtopic=63258"]http://www.autoitscript.com/forum/index.php?showtopic=63258[/url]
;                   Nwfu in the topic [url="http://www.autoitscript.com/forum/index.php?showtopic=28112&st=0"]http://www.autoitscript.com/forum/index.ph...=28112&st=0[/url]
;                   FTDI (www.ftdi.com)for the overwhelming documentation, samples and dll
;=================================================================================================
; References:       [url="http://www.ftdichip.com/FTDrivers.htm"]http://www.ftdichip.com/FTDrivers.htm[/url]
;=================================================================================================
;
; ------------------------------
; FT Classic Interface Functions
; ------------------------------
; Notes:            The functions listed in this section are compatible with all FTDI devices.
;
; Functions:        _FT_CreateDeviceInfoList($lpdwNumDevs)
;                   _FT_GetDeviceInfoList($pDest, $lpdwNumDevs)
;                   _FT_GetDeviceInfoDetail($dwIndex, $lpdwFlags, $lpdwType, $lpdwID, $lpdwLocId, $pcSerialNumber, $pcDescription, $FT_HANDLE)
;                   _FT_ListDevices($pvArg1, $pvArg2, $dwFlags)
;                   _FT_Open($iDevice, $FT_HANDLE)
;                   _FT_OpenEx($pvArg1, $dwFlags, $FT_HANDLE)
;                   _FT_Close($FT_HANDLE)
;                   _FT_Read($FT_HANDLE, $lpBuffer, $dwBytesToRead, $lpdwBytesReturned)
;                   _FT_Write($FT_HANDLE, $lpBuffer, $dwBytesToWrite, $lpdwBytesWritten)
;                   _FT_SetBaudRate($FT_HANDLE, $lngBaudRate)
;                   _FT_SetDivisor ($FT_HANDLE , $usDivisor)
;                   _FT_SetDataCharacteristics($FT_HANDLE, $uWordLength, $uStopBits, $uParity)
;                   _FT_SetFlowControl($FT_HANDLE, $usFlowControl, $uXon, $uXoff)
;                   _FT_SetDtr($FT_HANDLE)
;                   _FT_ClrDtr($FT_HANDLE)
;                   _FT_SetRts($FT_HANDLE)
;                   _FT_ClrRts($FT_HANDLE)
;                   _FT_GetModemStatus($FT_HANDLE, $lpdwModemStatus)
;                   _FT_GetQueueStatus($FT_HANDLE, $lpdwAmountInRxQueue)
;                   _FT_GetDeviceInfo ($FT_HANDLE, $pftType, $lpdwID, $pcSerialNumber,  $pcDescription,  $pvDummy)
;                   _FT_GetDriverVersion ($FT_HANDLE, $lpdwDriverVersion)
;                   _FT_GetLibraryVersion ($lpdwDLLVersion)
;                   _FT_GetComPortNumber ($FT_HANDLE $lplComPortNumber)
;                   _FT_GetStatus($FT_HANDLE, $lpdwAmountInRxQueue, $lpdwAmountInTxQueue, $lpdwEventStatus)
;                   _FT_SetEventNotification($FT_HANDLE, $dwEventMask, $pvArg)
;                   _FT_SetChars($FT_HANDLE, $uEventCh, $uEventChEn, $uErrorCh, $uErrorChEn)
;                   _FT_SetBreakOn($FT_HANDLE)
;                   _FT_SetBreakOff($FT_HANDLE)
;                   _FT_Purge($FT_HANDLE, $dwMask)
;                   _FT_ResetDevice($FT_HANDLE)
;                   _FT_ResetPort($FT_HANDLE)
;                   _FT_CyclePort($FT_HANDLE)
;                   _FT_Rescan()
;                   _FT_Reload ($wVID, $wPID)
;                   _FT_SetResetPipeRetryCount ($FT_HANDLE,$dwCount)
;                   _FT_StopInTask ($FT_HANDLE )
;                   _FT_RestartInTask ($FT_HANDLE )
;                   _FT_SetDeadmanTimeout ($FT_HANDLE ,  $dwDeadmanTimeout)
;
; -------------------------------
; FT EEPROM Programming Interface
; -------------------------------
; Notes:            FTDI device EEPROMs can be both read and programmed using the functions listed in this section.
;
; Functions:        _FT_ReadEE ($FT_HANDLE, $dwWordOffset, $lpwValue)
;                   _FT_WriteEE($FT_HANDLE, $dwWordOffset, $wValue)
;                   _FT_EraseEE($FT_HANDLE)
;                   _FT_EE_Read (FT_HANDLE , $pData)
;                   _FT_EE_ReadEx (FT_HANDLE , $pData,  $Manufacturer,  $ManufacturerId,  $Description,  $SerialNumber)
;                   _FT_EE_Program (FT_HANDLE , $pData)
;                   _FT_EE_ProgramEx (FT_HANDLE , $pData,  $Manufacturer,  $ManufacturerId,  $Description,  $SerialNumber)
;                   _FT_EE_UASize (FT_HANDLE , $lpdwSize)
;                   _FT_EE_UARead (FT_HANDLE , $pucData,  $dwDataLen,  $lpdwBytesRead)
;                   _FT_EE_UAWrite (FT_HANDLE ,$pucData,  $dwDataLen)
; ----------------------------------
; Error further information Function
; ----------------------------------
; Notes:            Function to return further information from the other Functions
; Functions:        _USBFT_ErrorDescription($i_Error)
;=================================================================================================
; Changelog:    V 0.0.1     - Initial Release - Classic Interface and EEPROM sections done i think
;                           - Issue with _FT_GetDeviceInfoDetail needs further assistance
;                           - FT Extended API Functions - Still to be completed if call for it
;                           - FT Win32 API Functions - Still to be completed if call for it
;=================================================================================================

Thanks for reading

Wakido(NBJ)

edit: Added a 24 channel lighting desk

FTD2XX.dll_UDF.au3

FTD2XX.dll_UDF.au3_EXAMPLE.au3

24 Channel Desk.7z

Edited by NBJ

Share this post


Link to post
Share on other sites
JRowe

This looks very interesting. I believe it belongs in the Example Scripts forums.

Could you explain what exactly this is? Is it an interface to a particular microcontroller?

Share this post


Link to post
Share on other sites
NBJ

This looks very interesting. I believe it belongs in the Example Scripts forums.

Could you explain what exactly this is? Is it an interface to a particular microcontroller?

@JRowe Hi, its a udf for the dll driver supplied with the FTDI series of USB FIFO interface Integrated Circuit Devices.

They seem to be used in quite a few usb devices - there has been mention here on the forums 4 or 5 times over the years, but not for a while now.

My main reason writing it is because there is one of these little chips inside the Enttec DMX USB Pro, a DMX (standard for controlling theatre lighting etc) so the final aim is a EnttecDMXUSBPro UDF, which will allow control of DMX devices from within Autoit.

I am hoping that someone will look at the UDF and let me know if I have made any errors, especially in creating the DllStruct and dll calls.

Thanks

NBJ

PS if a mod feels this should be moved. Please do so. Cheers

Edited by NBJ

Share this post


Link to post
Share on other sites
james3mg

@JRowe Hi, its a udf for the dll driver supplied with the FTDI series of USB FIFO interface Integrated Circuit Devices.

They seem to be used in quite a few usb devices - there has been mention here on the forums 4 or 5 times over the years, but not for a while now.

My main reason writing it is because there is one of these little chips inside the Enttec DMX USB Pro, a DMX (standard for controlling theatre lighting etc) so the final aim is a EnttecDMXUSBPro UDF, which will allow control of DMX devices from within Autoit.

I am hoping that someone will look at the UDF and let me know if I have made any errors, especially in creating the DllStruct and dll calls.

Thanks

NBJ

PS if a mod feels this should be moved. Please do so. Cheers

I'm extremely interested in having the ability to send DMX data from an AutoIt application, but I can't test your UDF without having the dll itself ^_^ Please keep me informed as this project moves forward, especially if there's anything I can do to help.

Thanks

~james3mg

Edited by james3mg

"There are 10 types of people in this world - those who can read binary, and those who can't.""We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true." ~Robert Wilensky0101101 1001010 1100001 1101101 1100101 1110011 0110011 1001101 10001110000101 0000111 0001000 0001110 0001101 0010010 1010110 0100001 1101110

Share this post


Link to post
Share on other sites
NBJ

I'm extremely interested in having the ability to send DMX data from an AutoIt application, but I can't test your UDF without having the dll itself :) Please keep me informed as this project moves forward, especially if there's anything I can do to help.

Thanks

~james3mg

Sorry for the late reply, I've been on tour.

I will let you know how I go with the DMX interface. Initial testing is good.

Cheers

NBJ

Share this post


Link to post
Share on other sites
NBJ

Just a quick update - there is now a 24 channel lighting desk in beta, lots of error control not in there yet, but sending DMX reliably and smoothly.

if there is anyone interested I will post the exe.

not quite ready to post the source yet.

Thanks

NBJ

Share this post


Link to post
Share on other sites
james3mg

Just a quick update - there is now a 24 channel lighting desk in beta, lots of error control not in there yet, but sending DMX reliably and smoothly.

if there is anyone interested I will post the exe.

not quite ready to post the source yet.

Thanks

NBJ

I'm back, looking for anything I can get along these lines.

I also found the .dll at http://www.enttec.com/index.php?main_menu=Products&pn=70303&show=downloads in the "C++ Builder Example" .zip file...I assume that means that the device featured on that page (Openttec DMX USB interface) would allow me to control DMX devices from an AutoIt script? That would just make my ... year. Also, the c# class on that page is really short, and may (to someone familiar with C) tell us everything we need to know about calling the .dll for full 512 control, once we translated to AutoIt.

Anything I can do to help, I'd love to jump all over.

One more question, by the way, since you seem to be quite experienced with this type of equipment- my setup currently uses two DMX512 circuits ("A" and "B"), independent of each other (I believe these are referred to as two "universes"?) If I were to move over to this type of USB interface off a computer, is it possible to address two separate instances of these USB devices from the same computer, sending different signals down each line?

Thanks


"There are 10 types of people in this world - those who can read binary, and those who can't.""We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true." ~Robert Wilensky0101101 1001010 1100001 1101101 1100101 1110011 0110011 1001101 10001110000101 0000111 0001000 0001110 0001101 0010010 1010110 0100001 1101110

Share this post


Link to post
Share on other sites
NBJ

I'm back, looking for anything I can get along these lines.

One more question, by the way, since you seem to be quite experienced with this type of equipment- my setup currently uses two DMX512 circuits ("A" and "B"), independent of each other (I believe these are referred to as two "universes"?) If I were to move over to this type of USB interface off a computer, is it possible to address two separate instances of these USB devices from the same computer, sending different signals down each line?

Thanks

Hi James,

Yes they are 2 universes, and with the DMX USB PRO at least, you can address 2 individual devices.

Haven't tried with the Open as it has some timing issues, so I spent the extra $$ on a couple of PRO devices.

The software should work with the open device as well, I can get hold of one, so when I do I will let you know.

- added a 24 channel lighting desk in post one.

Cheers

NBJ

Edited by NBJ

Share this post


Link to post
Share on other sites
james3mg

the nomenclature has me a bit confuzzled here...sorry ;)

I looked at the Pro device, and I see the two DMX plugs- but one looks like it's male and the other looks like it's female. When you say the pro can address two "devices", do you mean I need two of those pro boxes, or that a single pro box can address two independant universes? And if the latter, do I just need to get a female-to-female adapter, since both the plugs (currently) running from the lighting board are male ends? Their website isn't fully clear to someone like me, learning by the seat of their pants, lol.

Thanks again

Edit: I found in their user manual information that says one plug is "in" (from a controller) and one is "out" (to fixtures). So I assume that I actually need two "Pro" boxes to control my two lighting universes, and the difference is that the driver for the Pro device understands there may be more than one connected to the computer, is that right?

Edited by james3mg

"There are 10 types of people in this world - those who can read binary, and those who can't.""We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true." ~Robert Wilensky0101101 1001010 1100001 1101101 1100101 1110011 0110011 1001101 10001110000101 0000111 0001000 0001110 0001101 0010010 1010110 0100001 1101110

Share this post


Link to post
Share on other sites
james3mg

NBJ:

I finally tried out your 24-channel desk...very nice! I like some of the options it has built in...it seems very useable and configurable for your setup and show. Also, I finally understand what you meant by a 24-channel desk; I thought you were only being able to address the first 24 dmx channels, which I see is not the case. Please ignore my comment about how one might be able to expand to a full DMX 512 program. :evil:

One suggestion I have that I would need to make this extremely useful (to me), is the ability to have several sets of "patch" configurations. For instance, rather than slider 1 always controlling DMX channel 1, I'd like to be able to specify which DMX channels are controlled by slider 1. That way, slider 1 may be controlling all red lights pointing at the stage right wing, slider 2 may be all green lights pointing there, and slider 3 may be all blue lights pointing there. So by pushing up sliders 2 and 3, I'd bathe the stage right wing in a light blue. Or another patch setup might be that slider 1 was all lights pointing at front-and-center, slider 2 was stage right and slider 3 was stage left. It grants flexability to the desk: otherwise, if it's 1:1 with the DMX channels, I'd have to make a button that might affect channels 1,2,3,8,9,10,15,16&17: that button would turn them all on gradually, sure, but what if I wanted it "just a little" darker? I'd have to pull each slider down 10% manually and one-at-a-time, or have a slew of buttons for every possible combination of lighting that I wanted.

Other than that suggestion, (which is ONLY a suggestion, since you asked for it...please don't take it as more than that), this is a GREAT bit of programming- I love the setup!

I'm not completely sure how to use the "group" buttons above each slider, but that's probably due to my own inexperience with quality lighting setups, lol!

Nice work! ;)

Edited by james3mg

"There are 10 types of people in this world - those who can read binary, and those who can't.""We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true." ~Robert Wilensky0101101 1001010 1100001 1101101 1100101 1110011 0110011 1001101 10001110000101 0000111 0001000 0001110 0001101 0010010 1010110 0100001 1101110

Share this post


Link to post
Share on other sites
NBJ

NBJ:

I finally tried out your 24-channel desk...very nice! I like some of the options it has built in...it seems very useable and configurable for your setup and show. Also, I finally understand what you meant by a 24-channel desk; I thought you were only being able to address the first 24 dmx channels, which I see is not the case. Please ignore my comment about how one might be able to expand to a full DMX 512 program. :evil:

Well it really does only access the first 24 channels and as it is a 1:1 patch (as I haven't added patching yet :evil:_) it really only does 24 channels

One suggestion I have that I would need to make this extremely useful (to me), is the ability to have several sets of "patch" configurations. For instance, rather than slider 1 always controlling DMX channel 1, I'd like to be able to specify which DMX channels are controlled by slider 1. That way, slider 1 may be controlling all red lights pointing at the stage right wing, slider 2 may be all green lights pointing there, and slider 3 may be all blue lights pointing there. So by pushing up sliders 2 and 3, I'd bathe the stage right wing in a light blue. Or another patch setup might be that slider 1 was all lights pointing at front-and-center, slider 2 was stage right and slider 3 was stage left. It grants flexability to the desk: otherwise, if it's 1:1 with the DMX channels, I'd have to make a button that might affect channels 1,2,3,8,9,10,15,16&17: that button would turn them all on gradually, sure, but what if I wanted it "just a little" darker? I'd have to pull each slider down 10% manually and one-at-a-time, or have a slew of buttons for every possible combination of lighting that I wanted.

What you are really after then is submasters. - however operating submasters live on a PC is quite a challenge (physically for the operator).

Which is sort of what the buttons do, except that at the moment the buttons don't have an "ADD" function - only a xFade function. the plan is to use the 'Group' buttons to group like faders, so you can control a group with one fader - but that will come later, this Desk was designed for a small venue (infact they only have 12 dimmers and a couple of LED colour changing parcans. :idea:

Other than that suggestion, (which is ONLY a suggestion, since you asked for it...please don't take it as more than that), this is a GREAT bit of programming- I love the setup!

I'm not completely sure how to use the "group" buttons above each slider, but that's probably due to my own inexperience with quality lighting setups, lol!

Nice work! ;)

Thanks for the feed back - greatly appreciated.

btw - Groups not implemented yet :) so understandable that you cant get them to work :D

Also on your previous question - yes you can address 2 devices simultaneously. I am sure you can with the non pro also - but I haven't tested that.

Cheers

Edited by NBJ

Share this post


Link to post
Share on other sites
james3mg

Well it really does only access the first 24 channels and as it is a 1:1 patch (as I haven't added patching yet :evil:_) it really only does 24 channels

Sure, but I'd thought that was a limitation of the UDF, not your specific desk. The UDF doesn't have any issues controlling all 512 channels, does it?

Also on your previous question - yes you can address 2 devices simultaneously. I am sure you can with the non pro also - but I haven't tested that.

Cool, thanks! I think what I'm going to do is program my own desk first, to make sure I can do everything I want to, then I'll actually buy one of the devices :evil: So I'll take a look at the UDF and start plugging that in to my script as I develop it, and let you know if I have any syntax questions with the UDF that aren't covered in the function descriptions.

It would be very handy to have a sample of the minimum script/UDF calls needed to control even one channel, so I could get a feel for which functions have to be called in order, for instance. You know, if you have time :idea:;)

Thanks again! I've gotta tell you, I'm very excited about this!

Edit: I just went up to your OP and saw (for the first time, somehow) that you've got an example script. Please ignore me when I'm being stupid :)

Edited by james3mg

"There are 10 types of people in this world - those who can read binary, and those who can't.""We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true." ~Robert Wilensky0101101 1001010 1100001 1101101 1100101 1110011 0110011 1001101 10001110000101 0000111 0001000 0001110 0001101 0010010 1010110 0100001 1101110

Share this post


Link to post
Share on other sites
james3mg

I'm trying to start my way through your example file, and I'm feeling a little bit ;) at the moment. Bear with me please if you will, and I'll eventually get it all straight in my head

----------------------

First, a specific fatal error report: when I run the example script (after copying the .dll file and your UDF file into the same directory), I get an error

Subscript used with non-Array variable.:
Return $v_Result[0]
Return $v_Result^ ERROR
Digging further, I started by checking the DLLOpen() value, and it was fine, so it's finding the dll. I then asked the UDF to report the @error value after the DLLCall() in _FT_CreateDeviceInfoList, and it returns an error level of 3, which according to the help file means, "function" not found in the DLL file.

Do I have an incorrect version of the dll with differently named functions in it? It reports itself as FTDI FTD2XX Drivers, version 2.1.4.1

----------------------

Now, a general comment on the UDF, if I may.

If I'm reading this correctly, _FT_CreateDeviceInfoList() should ALWAYS be called with $lpdwNumDevs as the single parameter, since it's been pre-defined by the UDF as a global DLLStruct for this use. Shouldn't that be hard-coded into the UDF then, rather than as a parameter, so it's not called with some other variable (one that hasn't been already defined as a DLLStruct)? Or maybe the function parameter should be ByRef, and defined as the requisite DLLStruct within that function itself, in case there is actually a reason to have more than one variable of this type?

I feel like this type of system may apply to other functions throughout the UDF as well, and I just want to make sure I know what I'm looking at. It is, after all, entirely likely that I've just missed the reasons behind your doing it as you have, which would inevitably lead to errors on my part in my script. So any insight into the reasons you set the functions up this way would be appreciated :evil:

Thanks :evil:

Edited by james3mg

"There are 10 types of people in this world - those who can read binary, and those who can't.""We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true." ~Robert Wilensky0101101 1001010 1100001 1101101 1100101 1110011 0110011 1001101 10001110000101 0000111 0001000 0001110 0001101 0010010 1010110 0100001 1101110

Share this post


Link to post
Share on other sites
NBJ

Hi,

Oh - Um - Brain Failing - was such a long time ago when I wrote the UDF for the FTD2xx.dll UDF

I am using a new UDF specifically for the Enttec DMX USB devices these days -

Its been modified since the one above.

Basically if I remember correctly in the new UDF you start the device then use

SendDMX($ahDMXValues[512]) - or DMXSend() cant remember - I'll have a look as soon as I get some time.

to send out the DMX values.

it does create a dllstruct for the array to pass to the device, so there is probably a little excess fat in the program than requred.

Share this post


Link to post
Share on other sites
james3mg

OK, I'd love to take a look at your new UDF, if you're willing. I assume this was more an answer to my comments on the programming, not an answer to the error I was getting? Maybe it would help myself and others to post a link to where we can get the correct dll for your example/udf file in the OP, if you know where it can be obtained from.

Thanks again


"There are 10 types of people in this world - those who can read binary, and those who can't.""We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true." ~Robert Wilensky0101101 1001010 1100001 1101101 1100101 1110011 0110011 1001101 10001110000101 0000111 0001000 0001110 0001101 0010010 1010110 0100001 1101110

Share this post


Link to post
Share on other sites
NBJ

sorry my brain is not allowing me to concentrate on this right now.

give me a couple of days and I'll get it sorted.

I was suggesting a method for making your program rather than trying a fix for the UDF above.

The UDF above was my first delve into dll calls and stucts etc, so I am sure it is full of errors and the synax and methodology can be improved.

I will have a UDF called DMX_[Enttec_USB_FTD2xx]_UDF.au3 ready for showing soon - basically I need to document - (which I wish I had done when I was writing it, moths ago, hope the memory is still there).

The New UDF is more specifically designed for the Enttec devices rather than the generic UDF for the FTD2xx.dll

I will need to spend some time and have a look at the UDF above and see whats happening.

The dll should be from enttec.com in the driver pack for the DMX USB PRO or the openDMX devices.

I have pulled out a the section below for you to have a look at.

Sorry I haven't been more helpful yet.

Neil

#Region - Examples
ConsoleWrite(@CR & '!------------_DMX_NumberOfDevices()-----------------------')
$iNumDevices = _DMX_NumberOfDevices()
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$iNumDevices=' & $iNumDevices)
ConsoleWrite(@CR & '----------------------------------------------------------')

ConsoleWrite(@CR & '!------------_DMX_DeviceSerialNumberFT()-----------------------')
$iDeviceSerialNumberFT = _DMX_DeviceSerialNumberFT($iNumDevices - 1)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$iDeviceSerialNumberFT=' & $iDeviceSerialNumberFT)
ConsoleWrite(@CR & '----------------------------------------------------------')

ConsoleWrite(@CR & '!------------_DMX_DeviceDescription()-----------------------')
$iDeviceDescription = _DMX_DeviceDescription($iNumDevices - 1)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$iDeviceDescription=' & $iDeviceDescription)
ConsoleWrite(@CR & '----------------------------------------------------------')

ConsoleWrite(@CR & '!------------$iDeviceLocation()-----------------------')
$iDeviceLocation = _DMX_DeviceLocation($iNumDevices - 1)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$iDeviceLocation=' & $iDeviceLocation)
ConsoleWrite(@CR & '----------------------------------------------------------')


ConsoleWrite(@CR & '!------------_DMX_OpenDevice()----------------------------')
$hDeviceHandle = _DMX_OpenDevice($iNumDevices - 1)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$hDeviceHandle=' & $hDeviceHandle)
ConsoleWrite(@CR & '----------------------------------------------------------')

ConsoleWrite(@CR & '!------------_DMX_BytesInBuffer()----------------------------')
$QueueStatus = _DMX_BytesInBuffer($hDeviceHandle)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$QueueStatus=' & $QueueStatus)
ConsoleWrite(@CR & '----------------------------------------------------------')

ConsoleWrite(@CR & '!------------_DMX_DeviceSerialNumber()----------------------------')
$DMX_DeviceSerialNumber = _DMX_DeviceSerialNumber($hDeviceHandle)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$DMX_DeviceSerialNumber=' & $DMX_DeviceSerialNumber)
ConsoleWrite(@CR & '----------------------------------------------------------')

ConsoleWrite(@CR & '!------------_DMX_DeviceDetails()----------------------------')
$DMX_DeviceDetails = _DMX_DeviceDetails($hDeviceHandle)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$DMX_DeviceDetails=' & $DMX_DeviceDetails)
ConsoleWrite(@CR & '----------------------------------------------------------')

$sSendDMX = _DMX_SendDMXVariableDataLength($hDeviceHandle, $DMXValues, $iArrayStart)
$sSendDMX = _DMX_SendDMX($hDeviceHandle, $DMXValues, 513)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$sSendDMX =' & $sSendDMX)
ConsoleWrite(@CR & '----------------------------------------------------------')


$sSendDMX = _DMX_SendDMX($hDeviceHandle, $DMXValues)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$sSendDMX =' & $sSendDMX)
ConsoleWrite(@CR & '----------------------------------------------------------')

ConsoleWrite(@CR & '!------------_DMX_ResetDevice()----------------------------')
$DMX_ResetDevice = _DMX_ResetDevice($hDeviceHandle)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$DMX_DeviceDetails=' & $DMX_ResetDevice)
ConsoleWrite(@CR & '----------------------------------------------------------')


ConsoleWrite(@CR & '!------------_DMX_CloseDevice()----------------------------')
$hDeviceHandle = _DMX_CloseDevice($hDeviceHandle)
ConsoleWrite(@CR & 'Error=' & _USBFT_ErrorDescription(@error))
ConsoleWrite(@CR & '$hDeviceHandle=' & $hDeviceHandle)
ConsoleWrite(@CR & '----------------------------------------------------------')

Ok - so it will be more than a few days - I am sorry, I have a major project due mid Feb - So it will have to wait until after that, Really sorry

Edited by NBJ

Share this post


Link to post
Share on other sites
james3mg

Ok - so it will be more than a few days - I am sorry, I have a major project due mid Feb - So it will have to wait until after that, Really sorry

No problem, do your thing :mellow: I'm glad you're still around...we'll get back on this eventually. I'm still working on the "design" of my desk, so I haven't gotten to the point of actually implementing the DMX stuff yet.

If you would, when you're back and available for some dialog, please send me a PM...my subscription for this topic will probably have expired again so I won't notice when you post. But a PM will e-mail me so I don't miss it.

Thanks!


"There are 10 types of people in this world - those who can read binary, and those who can't.""We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true." ~Robert Wilensky0101101 1001010 1100001 1101101 1100101 1110011 0110011 1001101 10001110000101 0000111 0001000 0001110 0001101 0010010 1010110 0100001 1101110

Share this post


Link to post
Share on other sites
VAG

Hi NBJ, I think your original FTD2XX.dll_UDF.au3 is still useful to some of us dealing with FIFO devices other than DMX. Like me, I'm currently exploring your UDF to control my multi-channel audio relay circuit switcher with a build-in FT245R interface. Posted Image

Initially, I've also built my 1st VB.Net control app based on the example in FTDI website. But now I found your UDF is more useful as I'm integrating some other AutoIt UDF stuffs to create a complete "Software + Hardware" test system entirely in AutoIT script. Posted Image

Thank you and looking forward to your release of both UDFs in the Example Scripts section...

Share this post


Link to post
Share on other sites
VAG

Hi NBJ, in your udf, you mentioned about some unfinished extended API functions. Happens that I need to use one of it to set my FT245R FIFO to "Asynchronous Bit Bang Mode". So I tried to fill in the gap for this function:

Global $uMask = ' '
Global $uMode = ' '
.
.
.
#Region Extended API Functions

;Customized methods for FT245R
;FT_SetBitmode (FT_HANDLE ftHandle, UCHAR ucMask, UCHAR ucMode)
;-----------------------------
Func _FT_SetBitMode($FT_HANDLE, $uMask, $uMode)
 $v_Result = DllCall($v_Dll, 'long', 'FT_SetBitMode', 'ptr', $FT_HANDLE, 'byte', $uMask, 'byte', $uMode)
 Return $v_Result[0]
EndFunc

#EndRegion Extended API Functions

But when I tried to call this function to set all my 8 channels FIFO to output using "255" with "Asynchronous Bit Bang Mode" using "1", part of the channels are still not set properly. This doesn't happens on my VB code. You have any suggestions on this? Thanks in advance.Posted Image

ConsoleWrite(@CR & '!------------ FT_SetBitmode ($FT_HANDLE, $uMask, $uMode)')
$Do = _FT_SetBitMode($FT_HANDLE, 255, 1) ;Asynchronous Bit Bang, all channels to output
ConsoleWrite(@CR & _USBFT_ErrorDescription($Do))

Share this post


Link to post
Share on other sites
VAG

Finally get it working, seems that the problem is in the $lpBuffer type in FTD2XX.dll_UDF.au3 Posted Image

Change from 'char[128]' to 'BYTE[128]' :

Global $lpBuffer = DllStructCreate('BYTE[128]')

ConsoleWrite(@CR & '!------------ FT_SetBitmode ($FT_HANDLE, $uMask, $uMode)')
$Do = _FT_SetBitMode($FT_HANDLE, 255, 1) ;Asynchronous Bit Bang, all channels to output
ConsoleWrite(@CR & _USBFT_ErrorDescription($Do))

ConsoleWrite(@CR & '!------------_FT_Write($FT_HANDLE,  $lpBuffer,  $dwBytesToWrite,  $lpdwBytesWritten)')
DllStructSetData($lpBuffer, 1, 255) ;Set all channels to high
$Do = _FT_Write($FT_HANDLE, $lpBuffer, 1, $lpdwBytesWritten) ;8 channels = 8-bit is 1 byte only
ConsoleWrite(@CR & _USBFT_ErrorDescription($Do))
ConsoleWrite(@CR & DllStructGetData($lpBuffer, 1))
ConsoleWrite(@CR & DllStructGetData($lpdwBytesWritten, 1))

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×