Also, the relay module has an FTDI chip, which implies serial communication.
Anybody home???
Take example app for serial control and adapt it for your needs. Good luck!
The project that I have mentioned, several times, is from Xojo’s Example Projects, Communication, Serial. I have been adapting the project for my needs as you suggested, but it is still not producing any results, which was my reason for joining this conversation.
Is there any way to tell if the commands that I’ve issued are actually being transmitted?
Thanks for the “Good luck” wishes, but I would certainly appreciate some real help.
Try a different baudrate like 115200 or 57600.
Probably a settings thing in the serial class.
Also i always make subclasses for serial, which might help
Thanks, Derk. I will experiment with the baudrate settings to see if they might make a difference.
Christian, please allow me to apologize for being somewhat curt and presumptuous of your help. I do appreciate the suggestions that you made and should not have presumed on your kindness for further help. Sincere apologies!
Take care,
Don
The FTDI device acts as a virtual Com Port (VCP). Both Macintosh and Windows have built-in VCP drivers, that usually work fairly well with the FTDI chip, though the VCP driver in older versions of these operating systems were not as good. FTDI has their own driver that you can download, and it usually works better with their devices than the older OS built-in drivers.
http://www.ftdichip.com/FTDrivers.htm
Another thing to consider is that short chunks of data may sit in a buffer somewhere and not get sent to the device. (It sometimes appears that the OS waits for a minimum amount of data before it sends it out.) You can force it to be sent by following your serial.write command with a serial.flush command.
Hi Robert,
Thanks for the info. I’ve been following the write commands with flush commands, so I think the problem is deeper than that. I checked the link that you posted, but once again, that puts me in new territory. I’ve done API calls from VB 6, but not Xojo, so I will have to do some homework & experimenting to make that work.
Here’s a rookie question for you: Is it necessary to install the FTDI driver or does the Xojo Serial control handle that? Obviously, I have not done that, which may be the root of my problem.
Thanks much.
In theory, it shouldn’t be necessary to install any additional drivers, because the FTDI chip acts as a virtual com port (VCP) and the computer OS has a VCP driver built in. Somewhere on the FTDI website they state that the drivers on Windows 10 are compatible with their chip as are the current MacOS drivers. Apparently, the VCP drivers on earlier versions of MacOS and Windows had some issues. It was a few months ago when I found that comment, but I can’t locate it now.
Where I found problems with the standard OS drivers was with their handling of RTS/CTS and DSR/DTR flow control. I wasn’t able to get that to work until I changed to the FTDI driver. If your relay module requires the use of hardware handshake signals, then the driver could be the problem.
If you decide to install the FTDI driver, you don’t have to make any changes to Xojo or your Xojo program. The new driver simply replaces the existing one, and it’s completely transparent.
Great - I will give it a try.
Thanks!
Don
Hi. I thought I was making progress with this but hit a wall. I have this relay.
https://www.sainsmart.com/products/16-channel-usb-hid-programmable-control-relay-module
Has anyone got this working. I read above that indicated Julian had it working. I think I can connect to it and when I write to it it returns a 65 so I must be on the right track, but no relays are activating. I’ve tried various numbers in the byte. Here is how I am currently trying it.
I connect with HIDAPIDeviceMBS
[code] 'MsgBox "Device: " + d.ManufacturerString
'MsgBox "OR Length: " + str(MYHID.OutputReportLength)
dim buf as new MemoryBlock(65)
dim r as integer
'buf.UInt8Value(0) = 0 // First byte is report number
'buf.UInt8Value(1) = 255
'buf.UInt8Value(2) = 1
buf.byte(0)=0
buf.byte(1)=255
buf.byte(2)=1
r = MYHID.Write(buf)
'r = MYHID.SendFeatureReport(buf)
MsgBox str®
MYHID.Close[/code]
If the relay board uses an FTDI USB interface chip, as has previously been stated, then you should be accessing it as a serial port, not an HID USB device.
The reason why you can see it as an HID device is because the FTDI chip presents two interfaces to the computer when you plug it in:
- An HID interface for configuration of the device by the end product manufacturer.
- A VCP interface for actual use.
You don’t need to worry about chip configuration. That’s been done. So the HID interface is not applicable. You control the relays using the VCP (virtual com port) interface, which behaves like a serial port, and you use XOJO’s serial port routines to communicate with the device and control it.
It doesn’t show up as a serial device. I think it is specifically a HID device
According to Sainsmart and from the code posted by JC the device uses the HID (i.e. D2XX) interface and not serial (i.e. VCP). Even though the computer may recognize the device because VCP drivers exist, that does not mean the device/relay was designed to use the serial COM interface. I am not really familiar with communicating with low-level HID devices, but it looks like JC used the “SendMessageMemory” command and you are using the “Write” command. I would try to duplicate what he did as much as possible. You could also contact Sainsmart as they suggest (“We will offer you a detailed project introduction and their source code(Contact us via support@sainsmart.com).”).
They sent me a few lines of C# source code, I don’t have the skills to make any sense out of it, I’m more of a RealBasic kind of guy 
If you can post the C# code, someone may be able to translate it into XOJO.
I not convinced that this is actually for this module.
Sample C# code :
private void button1_ON_Click(object sender, EventArgs e)
{
serialPort1.Write(new byte[] { 0xFF, 0x01, 0x01 }, 0, 3);
}
private void button1_OFF_Click(object sender, EventArgs e)
{
serialPort1.Write(new byte[] { 0xFF, 0x01, 0x00 }, 0, 3);
}
Here is the latest I have, it returns that bytes have been written but relays aren’t activating. .Write returns bytes written, .SendFeatureReport returns an error.
[code] dim MYHID as HIDAPIDeviceMBS = HIDAPIDeviceMBS.Open(1046,20512,"")
'dim MYHID as HIDAPIDeviceMBS = HIDAPIDeviceMBS.OpenPath(“USB_0416_5020_fd132300”)
'this seems to give same results as .Open
dim buf as new MemoryBlock(64)
dim r as integer
buf.byte(0)=0
buf.byte(1)=255
buf.byte(2)=1
r = MYHID.Write(buf)
'r = MYHID.SendFeatureReport(buf)
MsgBox "Bytes Written: " + str®
MYHID.Close
'1046 Nuvoton 20512 HID Transfer USB_0416_5020_fd132300 -1
[/code]
It seems strange that their sample code would use serial port writes if it truly is an HID device. Are you able to see the part number of the USB interface chip on your circuit board?
NUC122ZC1