LabJackSupport

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?

Our DAQFactory for LJM page is chock full of nuggets so I would go through it thouroughly, and take a good look at the LJM_Basic.ctl example that demonstrates many key things. Per AzeoTech's point about using a DF Channel you can find info here: http://labjack.com/support/software/examples/ljm/daqfactory#LinkingChannels Per AzeoTech's point about DF taking care of Handle, the following hints at that: http://labjack.com/support/software/examples/ljm/daqfactory#Opening ... and then does not seem to be clearly stated, but you can see the example script is passing an LJM identifier as the first parameter: http://labjack.com/support/software/examples/ljm/daqfactory#Script

See "Opening a Device" here: https://labjack.com/support/software/examples/ljm/daqfactory DAQFactory's D# is the Identifier parameter passed to the open call: https://labjack.com/support/software/api/ljm/function-reference/ljmopens "To specify an identifier, use a serial number, IP address, or device name." With USB, serial number would be the common choice to pass.

The modbus write function is documented here: https://labjack.com/support/datasheets/t-series/scripting/labjack-library I don't spot anything wrong in your calls to set FIO0 to output-high and output-low. Check out the Lua example "Toggle DIO 1Hz". We can continue troubleshooting that, but my approach might be a little different. How about using USER_RAM0_U16 and having the Lua script increment it when desired. Then DAQFactory can read that register and note if it has changed from the previous value. That way you never miss a trigger. https://labjack.com/support/datasheets/t-series/lua-scripting

To talk to an EI-1050 through a U3 requires special function calls as described in "UD Library Communication" here: https://labjack.com/support/datasheets/accessories/ei-1050 Have you tried "EI1050 U3.ctl"? https://labjack.com/support/software/examples/ud/daqfactory

The comment you are seeing in LabJack forum topic is about directly controlling a solid-state relay (SSR), which is best done using "sinking" control. When you do that you need to change the DIO between input (relay off) and output-low (relay-on). https://labjack.com/support/app-notes/Controlling-Relays With the RB12, however, you just change the DIO between output-high (module off) and output-low (module on). The following is from the RB12 Datasheet: "The RB12 behaves with inverted or negative logic. For output modules that means the applicable LabJack DIO must be set to output-low to enable the I/O module. Output modules will be disabled with the DIO set to input or output-high." https://labjack.com/support/datasheets/accessories/rb12

We discussed this issue today as a group and noticed one other potential issue. It doesn't look like you properly define your "numWrite" or "array" variables. There is a chance that you could be instructing DAQFactory to write no bytes to the device instead of two. You can easily test this by modifying the line: AddRequest(ID, LJ_ioI2C_COMMUNICATION, LJ_chI2C_WRITE, numWrite, array, 0) to be: AddRequest(ID, LJ_ioI2C_COMMUNICATION, LJ_chI2C_WRITE, 2, array, 0)

It looks like your device isn't receiving an "ACK" from your I2C slave sensor so the I2C packet is failing. Can you double check the slave address and make sure that you have pull-up resistors installed? In our I2C app-note we recommend 4.7k resistors. If you haven't already tried switching to the EIO0 and EIO1 ports, please do that as well.

Sounds like once per second you want to read a value that is the total duty cycle of a waveform over that last second. So if the signal was high 50 ms, low 450 ms, high 150 ms and low 350 ms, you would get a reading of 20% for that 1 second. The duty-cycle measurement timer mode measures every cycle, not the overall duty cycle of some time period, so that will not do what you describe. The only way I can think of to do it in hardware, so DF can read the value once per second as you describe, would be to write a Lua script that measures the percent on of each second and puts that value in user-ram. Sounds like a fairly easy script.

I took a look at the ACS712 and have 2 comments: 1. The nominal offset is half the supply voltage. If the supply voltage is exactly 5.0, then the offset will be 2.5, but if you are using VS to power the sensor you should read back the actual value of VS in real time and use that in your math rather than assuming 5.0. 2. The nominal sensitivity is 66 mV/A, which means a swing of +/-1.98 volts, not +/-2.5 volts.

A simple option for a long interval like this is to simply use DIO#_EF_READ_A_AND_RESET (rather than DIO#_EF_READ_A) and tell DF to only read that register every 10 seconds. The classical solution is to read DIO#_EF_READ_A as often as you want, but store historical values so whenever you want to display a 10 second count you subtract the count from 10 seconds ago from the current count.