LabJackSupport

Unfortunately, LabJack does not have any robust solutions for 4-20mA output. Sometimes you can use a DAC output for 4-20mA based on the load impedance, but that will not work here. There are some 0-5V to 4-20mA conditioning modules out there, but I think it would be more expensive and overall worse than the PLC idea. There are also some inexpensive temperature PID controllers with 4-20mA output. It sounds like you want to handle the control in software so most PID controllers would not be suitable, but I did find the following controller that appear to have a voltage to 4-20mA retransmission configuration for a bit less than a signal conditioner: https://www.automationdirect.com/adc/shopping/catalog/process_control_-a-_measurement/temperature_-z-_process_controllers/modular_temperature_controllers

The 255 values means that the LabJack is not detecting any change in the data line. That could be due to a software I2C configuration issue or hardware issue. If your software setup works with one hardware setup but not the other, it should indicate that there is some hardware related issue. However, if you are running your tests on separate computers I would not completely rule out software differences/issues. I would suggest probing out the data and clock lines with an oscilloscope or logic analyzer to see what is going on with the bus.

I think that the error is likely due to some DAQFactory configuration. I ran the section of code you provided without any valid I2C connection and I do not see any errors. I can force the error if I comment out the array declaration: //private dataArray I suspect the issue is something related to the variable declaration or maybe scope. The behavior we expect without a valid I2C connection is to read a logic high since the I2C bus should have pullup resistors installed. That should return an array of {255,255,255,255,255}. Reading zeros would indicate that the sensor is holding the line low, but as discussed above I do not think this is the issue.

Ethernet devices such as the T4 and T7 support two TCP connections. Since you are using the U3, only USB is available and you cannot use the U3 in both the TDAC utility and DAQFactory at the same time. Closing the TDAC utility should automatically release the U3 connection to be claimed in other software, but you still may need to restart DAQFactory for everything to work as you expect. You might be erring out and skipping necessary setup otherwise. For example, you might skip execution of your startup sequence. Note that the LJTick-DAC update rate may be limited while stream is running. Stream should run at the highest priority interrupt context on the U3 microcontroller; it could interrupt normal TDAC command execution, causing TDAC commands to take longer to complete. The TDAC is controlled using I2C and the U3 I2C interface has a fairly slow maximum clock speed (150 kHz) before even considering the effects of processor loading from stream mode. We do not have any great ways to quantify the stream/TDAC performance impact broadly, so it is just something to be aware of.

If both LJStreamUD and our basic DAQFactory example are working as expected, then we can reasonably assume that the issue is something with the configuration of your program. As a starting point, there are a couple of things AzeoTech previously mentioned that we would strongly recommend changing. It looks like your LabJack header import does not handle the situation when using a 32-bit OS. We would recommend using the import used in our examples, like the following: using("device.labjack.") try include("c:\program files (x86)\labjack\drivers\labjackud.h") catch() include("c:\program files\labjack\drivers\labjackud.h") endcatch We would recommend not using 0 for the device ID, and instead defining and using a global ID as described in the following user's guide setup: https://labjack.com/pages/support?doc=/software-driver/3rd-party-applications/2-installing-and-starting-applies-to-ud-series/#section-header-two-u1fu Something else I noticed in your program is that you reconfigure the stream scan rate in multiple places. I would recommend making changes to ensure that you are only doing stream configuration in one sequence. Are you seeing any errors? Troubleshooting errors could be one way to go. You might also consider starting a new project and slowly build everything back out. Get things working with stream, then add additional functionality back in.

The Pinout for the U6 follows the same patterns as the UE9. The analog inputs are only the terminals labeled as AIN, the digital I/O are the FIO/EIO/CIO terminals. See the guide on our website, it has some minor updates: https://labjack.com/pages/support?doc=/software-driver/3rd-party-applications/33-channel-pinouts-applies-to-ud-series/#header-three-kcyya Also see the examples and other information on the following page: https://labjack.com/pages/support?doc=/software-driver/example-codewrappers/daqfactory-for-ud-windows/

We would tend to agree with Azeotech that you are more likely seeing a hardware related issue. Here are some other things to consider. Generally we recommend troubleshooting by running tests that isolate each potential source of the issue. Do you have any way to reasonably test your software without devices such as the pump and DC motors/controller connected? Even better, could you set up a test without anything connected besides a computer and LabJack, for example by setting up the DAQFactory program on a different computer elsewhere? We understand that this might not be possible depending on your control system setup, but either situation should help test whether the issue is in software since it eliminates the most likely hardware that could be causing issues. It looks like you may have ground loops in the wiring setup. The LabJack GND should be common to laptop GND through the USB connection. It looks like both the laptop and labjack GND are connected to screw ground, which could set up a ground loop. It also looks like multiple LabJack GND terminals are referenced to screw ground in multiple locations. We would suggest trying to reduce the number of ground connections. Ideally, LabJack GND should only be referenced to your screw ground in one location (if at all). We would suggest trying to eliminate these potential ground loops, and if possible isolate the LabJack/laptop from the pump and DC motor systems. That would help ensure that things such as inrush/flyback are not wiping out the USB interface or laptop more generally.

See the channel mapping in the following documentation: https://labjack.com/pages/support?doc=/datasheets/u3-datasheet/261-channel-numbers-u3-datasheet/ With the flexible IO such as FIO4-7, you should also ensure each line is set to analog input before trying to read them as analog inputs. That is done using the LJ_ioPUT_ANALOG_ENABLE_PORT or LJ_ioPUT_ANALOG_ENABLE_BIT IOTypes. See the following related pseudocode: https://labjack.com/pages/support?doc=/datasheets/u3-datasheet/412-configuration-u3-datasheet/

For the HX711 breakout, the color line side is all connections the load cell. That is described in the hookup guide here: https://learn.sparkfun.com/tutorials/load-cell-amplifier-hx711-breakout-hookup-guide?_ga=2.112634116.1828129323.1668558706-926891264.1636485443&_gac=1.127184639.1668558706.CjwKCAiAjs2bBhACEiwALTBWZQ17wY2q-S72-lITy9etdzRgpVlqs6s0DTZPlVHxjDIrFQ3UMMBlhBoCRYgQAvD_BwE#hardware-hookup- VCC could be connected to one of the DAC outputs set to 3.3V on the U3, GND to GND on the U3, then finally DAT and CLK to any of the digital IO such as FIO4 and FIO5. We have not tested with this board, but I suspect that the serial protocol could be implemented using our SPI feature, configuring the SPI clock to the CLK DIO pin and DAT to the MISO DIO pin. Both of those are configurable in software. From there, you should be able to clock out the necessary pulses to CLK by setting the number of bytes transfered. Some related SPI info: https://labjack.com/pages/support?doc=/datasheets/u3-datasheet/4110-spi-serial-communication-u3-datasheet/ If the SPI feature does not work well enough to handle the HX711 protocol, it might be possible to implement the protocol by using AddRequest calls to the DIO states directly, and putting small delays between them using the wait IOType as documented in the following pseudocode: https://labjack.com/pages/support?doc=/datasheets/u3-datasheet/4114-miscellaneous-u3-datasheet/

Yes, I suggest you use the LJTick-InAmp. Unless your load cell has signal conditioning, but I suspect it is a raw bridge circuit: https://labjack.com/pages/support?doc=/app-notes/sensor-types-app-note/bridge-circuits-app-note/

We do not recommend using the HX711 with the U3 unless you are familiar with serial protocols or want to learn more about working with low level digital communications. The HX711 uses what seems to be its own special serial protocol for communications. It does not appear to be a standard serial protocol, we do not directly support the serial protocol it uses, so it could require more attention to the low level communication details than other devices. An alternative amplifier could be our LJTick-InAmp: https://labjack.com/products/ljtick-inamp Are you using a breakout board, and if so could you please provide a link to its documentation? I think that there are a couple of different HX711 breakout boards, and the wiring might vary slightly depending on which one you are using.

We support a PWM output feature that runs continuously until stopped and a pulse output feature for a discrete number of pulses. For either feature you will need to do some configuration via a sequence in DAQFactory, or a startup configuration on the device. Also note that these features are only supported on certain FIO terminals for each device as described at the start of the feature documentation. Please see the following documentation: https://labjack.com/support/datasheets/t-series/digital-io/extended-features/pwm-out https://labjack.com/support/datasheets/t-series/digital-io/extended-features/pulse-out If you wanted to set up the feature as a startup configuration, you could use the following guide to set the feature up in our Kipling software, then use the power up defaults tab in Kipling to save it as a startup configuration: https://labjack.com/support/software/applications/t-series/kipling/register-matrix/configuring-pwm-output To do the configuration in a sequence, you can use the StartUp sequence in our LJM_Basic.ctl example as a starting point. You could remove the "AIN#_RANGE" LJM_eWriteName calls and add in your feature config calls. For example, to set the feature to pulse output on FIO0 (only valid on a T7) you would do make the following call: LJM_eWriteName(identifier, "DIO0_EF_INDEX", 2)

The issue may be to do with the maximum measurable time using your timer settings. As I had the example set up (using a 1MHz clock) the maximum time between edges is 65535/1000000 = 65ms and the resolution is 1/1000000=1 microsecond. There is a tradeoff between maximum measurable time and resolution depending on your timer clock frequency. Note that you must update the global variable clockFreq if you update the timer clock settings. Our timer documentation and pseudocode have additional information about the line to line feature and available timer clock settings: https://labjack.com/support/datasheets/u6/hardware-description/timers-counters/line-to-line-measurement https://labjack.com/support/datasheets/u6/high-level-driver/example-pseudocode/timers-counters

Apologies, the LJControlPanel issue seems to be an oversight. We will look into adding that support. In the meantime, I made a quick example demonstrating the line-to-line setup in DAQFactory. LineToLine.ctl

We support line-to-line timer features for both UD and T-series devices that should be able to achieve your goal. Please see the documentation for your given device below and let us know if we can help with anything further. For UD devices: https://labjack.com/support/datasheets/u3/hardware-description/timers-counters/timer-mode-descriptions/line-to-line-measurement For T-series devices: https://labjack.com/support/datasheets/t-series/digital-io/extended-features/line-line