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

You can stream the counters, but that will look a little different in terms of the channel configuration. To read Counter0 while streaming you must read channel 210 as an A to D I/O Type and channel 224 (TC_Capture) as an A to D I/O Type. The following page has additional information about the timer/counter stream channel changes: https://labjack.com/support/datasheets/u3/operation/stream-mode/digital-inputs-timers-counters We also have a few DAQFactory examples that stream timers/counters at the bottom of the following page: https://labjack.com/support/software/examples/ud/daqfactory

You can use an odd pin offset configuration. The valid pin offsets depends on the device. For the U3, 4-8 is valid. For the U6, 0-8 is valid. Your STARTUP1 script contains everything you should need to get going with a counter and your RawCounts channel looks set up correctly to read it. One thing I noticed is that you almost certainly have the wrong header file path, the include would not resolve correctly if you are using 64-bit Windows. You can better handle OS bitness related path issues by using a try catch block around the include. The following is what we use in our examples and should work correctly for 32-bit or 64-bit Windows: try include("c:\program files (x86)\labjack\drivers\labjackud.h") catch() include("c:\program files\labjack\drivers\labjackud.h") endcatch If you are still having issues with the counter not incrementing, I would recommend removing your actual signal and using a test signal. Connecting a wire to FIO7 and touching the free end to the inside back of a GND terminal should cause edges and therefore increment the counter some arbitrary amount. We would also recommend you try running the counter setup sequence manually after startup.

Did you try the tests described on our troubleshooting page? How does a DMM measurement compare to what the LabJack reports? If you can verify and understand the limitations of the U3, you can better understand your issue. If the U3 is operating within specification, but you still see higher noise than specified when measuring with the sensor, you know the issue is due to your sensor output or the U3 connection to the sensor. If the U3 is operating within spec and a DMM produces similar readings to the U3, you can infer that the issue is to do with your sensor. You could likely do some filtering or more specifically over-sample and average values in software to help account for some noise, but you do not want to try that before you know there is not some fundamental issue with your setup.

We would recommend you start by stepping back and tracking down your noise source. Our troubleshooting AIN application note has some guidance that could be helpful: https://labjack.com/support/app-notes/troubleshooting-AIN#TooMuchNoise Other than that, we agree with the response from Azeotech. 1) The T7 or U6 have the best resolution of any of our devices. We do not recommend the UE9 for new systems since the T7 performs better and costs less. We also have pro versions of the T7 and U6, which feature 24-bit resolution. The 24-bit converters have great noise rejection as well. 2) We sell an amplifier accessory called the LJTick-InAmp that could help improve your effective measurement resolution if you decide to stick with the U3: https://labjack.com/accessories/ljtick-inamp

Reading the AIN should not influence the digital features of the T4 unless you are using stream mode, in which case your maximum edge rate would drop. Before anything else, please ensure you are using the most recent release version of firmware. This is easiest to check using the Device Updater tab of Kipling. Also install the latest version of LJM. See our LJM installer page: https://labjack.com/support/software/installers/ljm I would recommend you start troubleshooting by closing DAQFactory and configuring the frequency in feature in Kipling as described in the guide below. Add your AIN channels to the active registers just so that everything is consistent with your current program: https://labjack.com/support/software/applications/t-series/kipling/register-matrix/configuring-reading-frequency If you do not have the issue in Kipling, that suggests something going on in your program. Otherwise there is likely something going on at a hardware level. Another good test would be to connect FIO4 to DAC1 and write a 1 to the register DAC1_FREQUENCY_OUT_ENABLE. This will generate a 10Hz square wave on DAC1 that the frequency in feature should agree with. The DAC1 frequency out function is described in our T-series datasheet: https://labjack.com/support/datasheets/t-series/dac

Which LabJack are you using? U12, UE9, U3, U6, T4 or T7. See related information here: https://labjack.com/support/app-notes/usb-communication-failure My first suggestion would be to remove the relay box from the system and see if the problem goes away.

I found another topic here about sinking or open-collector style of control: https://support.azeotech.com/topic/3761-output-low/?tab=comments#comment-12245 Turns out we have an example called Open-Collector_Output.ctl: https://labjack.com/support/software/examples/ud/daqfactory

The eStreamStart() identifier specifies the device handle: https://labjack.com/support/software/api/ljm/function-reference/ljmestreamstart That handle will essentially always be the same for each eStreamStart call if you're using the same T4. If you are going to stream in a series, you cannot do 4 consecutive starts like in your code with the same device. Multiple streams cannot run at the same time. You will need to start/configure the stream, do the reads, stop the stream, and then move on to the next set of channels to stream in your series. The structure would look more like this: LJM_eStreamStart(handle, {"AIN0", "AIN1", "AIN2", "AIN3", "AIN120", "AIN121", "AIN122", "AIN123", "AIN124", "AIN125",}, ...) while (more to read) { LJM_eStreamRead(handle, ...) } LJM_eStreamStop(handle) LJM_eStreamStart(handle, {"AIN126", "AIN127", "AIN48", "AIN49", "AIN50", "AIN51", "AIN52", "AIN53", "AIN54", "AIN55",}, ...) while (more to read) { LJM_eStreamRead(handle, ...) } LJM_eStreamStop(handle) LJM_eStreamStart(handle, {"AIN62", "AIN63", "AIN64", "AIN65", "AIN66", "AIN67", "AIN68", "AIN69", "AIN72", "AIN73",}, ...) while (more to read) { LJM_eStreamRead(handle, ...) } LJM_eStreamStop(handle) LJM_eStreamStart(handle, {"AIN74", "AIN75", "AIN76", "AIN77", "AIN78", "AIN79", "AIN86", "AIN88", "AIN90", "AIN92"}, ...) while (more to read) { LJM_eStreamRead(handle, ...) } LJM_eStreamStop(handle)

A LabJack customer asked about getting started with our original U12 device. They noted that the DAQFactory Quick Tutorial says it is for UD devices only. I suspect most of it applies to the U12, so perhaps AzeoTech support can comment on how to adapt the tutorial to a U12? https://labjack.com/support/software/3rd-party-applications/daqfactory/quick-tutorial

Just noticed this. It seems we get notified of new topics, but no notification for any posts after that. T series devices do not have a "Local ID" like our older devices. Instead the identifier options are serial number, IP address, or device name. You can edit the device name on the "Device Info" tab of Kipling, but does DAQFactory work with this string parameter?