As of May 2, 2022 the LabJack forums have been set to read-only.
If you are in need of support, please contact us via one of the methods described on our contact page.
It shows I2C usage, but not getting the ACKs. For that, read from the I2C_ACKS register after I2C communications. Refer to the I2C documentation for details:
Do I have to start the communication with the I2C_GO instruction and then send data to my driver or do I need to write on register and then send I2C_GO instruction?
You first write to the registers to load the TX data (I2C_NUM_BYTES_TX and I2C_DATA_TX) and specify the number of RX bytes to read (I2C_NUM_BYTES_RX), then write to the I2C_GO register to perform the I2C transactions.
The process and the registers are documented here:
Most of your code looks good. The one issue I spotted is that you are sending the address in TX bytes; the LabJack actually handles the slave address (and write/read bit) of the command in firmware, so you should start your transfer bytes array with your Auto-increment byte.
I would test to see if you get ACKS once you make that adjustment. If you still have no ACKS, double check all of your connections. Make sure your pull-up resistors are securely tied to the terminals. If you are using one of the DIO or VS to power your sensor I would instead recommend using one of the DAC lines set to 3.3V.
Your command is long, which is not necessarily a problem, but I would recommend testing with a shorter command to start anyway. Maybe try writing {0x80, 0xFF} to set the PWM0 duty cycle.
This page is great for visualizing the I2C bus with our devices:
The simulator I linked above will show you the LabJack I2C bus depending on your settings. I would recommend hooking up a logic analyzer or oscilloscope to better analyze the actual signal.
What are you using for your level shifter? If you are using something like our LJTick-DigitalOut5V, which is uni-directional, then you would not be able to see any ACKS from the I2C slave device.
We have some other troubleshooting suggestions on the bottom of this page:
We have an I2C example in the C/C++ examples download. It is in its more\i2c folder.
https://labjack.com/support/software/examples/ljm/c
It shows I2C usage, but not getting the ACKs. For that, read from the I2C_ACKS register after I2C communications. Refer to the I2C documentation for details:
https://labjack.com/support/datasheets/t-series/digital-io/i2c
Hi,
Thanks for your answer.
Do I have to start the communication with the I2C_GO instruction and then send data to my driver or do I need to write on register and then send I2C_GO instruction?
Is not very clear for me...
Thanks in advance
Toto
You first write to the registers to load the TX data (I2C_NUM_BYTES_TX and I2C_DATA_TX) and specify the number of RX bytes to read (I2C_NUM_BYTES_RX), then write to the I2C_GO register to perform the I2C transactions.
The process and the registers are documented here:
https://labjack.com/support/datasheets/t-series/digital-io/i2c
Hi,
I try to communicate with a TLC59208 RGB driver but it's not working. And I don't know if the communication is well working or not.
This is my code :
const char* I2C_WRITE_NAME = "I2C_DATA_TX";
const char* I2C_READ_NAME = "I2C_DATA_RX";
int numBytes;
char aBytes[20];// = { 0 }; // TX/RX bytes will go here
// SDA pin number FIO0
LJM_error = LJM_eWriteName(handle, "I2C_SDA_DIONUM", 0);
// SCL pin number FIO1
LJM_error = LJM_eWriteName(handle, "I2C_SCL_DIONUM", 1);
// I2C Clock Frequency
LJM_error = LJM_eWriteName(handle, "I2C_SPEED_THROTTLE", 65516); // 100kHz
// Options bits:
// bit0: Reset the I2C bus.
// bit1: Restart w/o stop
// bit2: Disable clock stretching.
LJM_error = LJM_eWriteName(handle, "I2C_OPTIONS", 0);
// Slave Address of the I2C chip = 64 (0x40)
LJM_error = LJM_eWriteName(handle, "I2C_SLAVE_ADDRESS", 64);
// Write 1 byte on the I2C chip
LJM_error = LJM_eWriteName(handle, "I2C_NUM_BYTES_TX", 20);
// No read on the I2C chip
LJM_error = LJM_eWriteName(handle, "I2C_NUM_BYTES_RX", 0);
int errorAddress;
numBytes = 20;
aBytes[0] = 0x40; // Slave Adress
aBytes[1] = 0x80; // Auto-Increment on all registers
aBytes[2] = 0x80; // 00h : Mode1
aBytes[3] = 0x08; // 01h : Mode2
aBytes[4] = 0xFF; // 02h : PWM0 - Duty Cycle 99.6% - RED
aBytes[5] = 0xFF; // 03h : PWM1 - Duty Cycle 99.6% - BLUE
aBytes[6] = 0xFF; // 04h : PWM2 - Duty Cycle 99.6% - GREEN
aBytes[7] = 0x00; // 05h : PWM3
aBytes[8] = 0x00; // 06h : PWM4
aBytes[9] = 0x00; // 07h : PWM5
aBytes[10] = 0x00; // 08h : PWM6
aBytes[11] = 0x00; // 09h : PWM7
aBytes[12] = 0xFF; // 0Ah : GRPPWM : not used, default value
aBytes[13] = 0x00; // 0Bh : GRPFREQ : not used, default value
aBytes[14] = 0x42; // 0Ch : LEDOUT0 : allow control of LED output 0/1/2
aBytes[15] = 0x00; // 0Dh : LEDOUT1
aBytes[16] = 0x92; // 0Eh : SUBADR1 default value
aBytes[17] = 0x94; // 0Fh : SUBADR2 default value
aBytes[18] = 0x98; // 10h : SUBADR3 default value
aBytes[19] = 0xD0; // 11h : ALLCALLADR default value
errorAddress = LJM_eWriteNameByteArray(handle, I2C_WRITE_NAME, numBytes, aBytes, &errorAddress);
LJM_error = LJM_eWriteName(handle, "I2C_GO", 1);
Do I miss something?
Best Regards,
Toto
Most of your code looks good. The one issue I spotted is that you are sending the address in TX bytes; the LabJack actually handles the slave address (and write/read bit) of the command in firmware, so you should start your transfer bytes array with your Auto-increment byte.
I would test to see if you get ACKS once you make that adjustment. If you still have no ACKS, double check all of your connections. Make sure your pull-up resistors are securely tied to the terminals. If you are using one of the DIO or VS to power your sensor I would instead recommend using one of the DAC lines set to 3.3V.
Your command is long, which is not necessarily a problem, but I would recommend testing with a shorter command to start anyway. Maybe try writing {0x80, 0xFF} to set the PWM0 duty cycle.
This page is great for visualizing the I2C bus with our devices:
https://labjack.com/content/i2c-simulator
*Edit: Restructured our response
Hi,
Yes I see my mistake for the address but it does not change anything.
I use a level shifter to convert the 3.3V to 5V. I try to test different pull-up resistor but it seems to have no impact and I still have no ACKS.
Is there a Labjack application to check what it is send on the I2C bus?
Best Regards
The simulator I linked above will show you the LabJack I2C bus depending on your settings. I would recommend hooking up a logic analyzer or oscilloscope to better analyze the actual signal.
What are you using for your level shifter? If you are using something like our LJTick-DigitalOut5V, which is uni-directional, then you would not be able to see any ACKS from the I2C slave device.
We have some other troubleshooting suggestions on the bottom of this page:
https://labjack.com/support/datasheets/t-series/digital-io/i2c