LabJackSupport

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.

Each range on the U6 is individually calibrated. When the calibration is applied you get actual volts, not volts * 100.

10 ppr and 10000 rpm gives you about 1667 pulses per second, so you can use a counter or a timer. See the following for an overview: https://forums.labjack.com/index.php?showtopic=1105 First try them in the test panel in LJControlPanel. I suggest you try out a simple hardware counter, and also try the 32-bit period input timer: https://labjack.com/support/datasheets/u3/hardware-description/timers-counters For an NPN signal you should be able to just connect to a DIO and GND as shown in Figure 2 here: https://labjack.com/support/app-notes/open-collector-signals

In terms of hardware, are you using a relay to switch the fan on and off? See the following app note and do initial testing using the test panel in LJControlPanel before you try to automate using DAQFactory: https://labjack.com/support/app-notes/Controlling-Relays

You want to use the "USER_RAM" registers. They are documented on scripting section of the T7 datasheet about half way down the page. Below the register descriptions is a short lua script example that reads from the USER_RAM0_F32 register (address 46000) and writes to the USER_RAM1_F32 register (address 46002). I highly recommend checking out the I2C_Utility script that we have for Lua (currently only posted to github, and released with the latest beta installer on our website): https://github.com/labjack/I2C-AppNotes/blob/master/LJM_Library/I2C_Abstraction_Layers/lua/Lua_I2C_Utils%20.7.lua The script (with no modifications) will search for any available slave addresses where the SDA line is DIO12 (EIO4) and SCL line is DIO13 (EIO5), look at line #92 to re-configure this. We have several I2C examples that use the I2C utility that you can look at for examples: https://github.com/labjack/I2C-AppNotes/tree/master/LJM_Library. All of the .lua examples should read data from the designated sensor and post some data to user ram registers. The IO-Expander example uses a few registers as "input" registers.

I don't see any obvious in your CTL (but it might have extra stuff you don't need). It looks like it is configuring a 32-bit period timer on FIO5. If you don't need the PWM, perhaps get rid of that and just use the default clock configuration and just go with your 1 period measurement timer on FIO4. If you have not already, you want to test your timer first using the test panel in LJControlPanel. https://labjack.com/support/datasheets/u3/hardware-description/timers-counters/timer-mode-descriptions/period-measurement-32 In the test panel, I suggest just the following 2 changes to the defaults to enable your 1 input timer on FIO4: # of Timers Enabled = 1 Timer 0 Mode = RISINGEDGES32 If that works with your signal, you can then go to "config defaults" in LJControlPanel and do these same settings and save them as the power-up default for your device. Then power cycle the U3 so they take effect. Now you don't need to do any configuration in DAQFactory ... just read the timer value.

The Ebay sensor you linked looks interesting because it runs off of 5 volts which you can get from the U3. It does not tell us how much supply current it needs, but I would think a sensor like this draws less than 50mA which is no problem for the U3 to provide from its VS terminals. (Note: The 200mA spec is likely the maximum current the PNP output switch can source.) The output is PNP, rather than the preferred NPN, so you will need to add a 4.7k pull-down resistor: https://labjack.com/support/app-notes/open-collector-signals At 900 RPM you are only getting 15-30 pulses per second. That might be enough to use a counter, but using a timer to measure the period of each pulse is a more likely solution: http://forums.labjack.com/index.php?showtopic=1105

The choice of rotation speed sensor is going to be impacted by your physical constraints, but any sort of encoder or sensor that gives you one or more pulses per revolution should be pretty easy to deal with. If you find some of interest post links to technical details and we can take a look. As for the load cell, to use one with the U3 you need an instrumentation amp such as the LJTick-InAmp: http://forums.labjack.com/index.php?showtopic=4376 https://labjack.com/support/datasheets/accessories/ljtick-inamp/appendix-d

There are a few things that are probably wrong with your code so I am going to point you to an example library we have slowly been working on to hopefully help you understand what the driver/device is doing and then suggest fixes to your code. This example code is for Matlab but it is still fairly useful as the naming still follows the AddRequest and GoOne format. https://github.com/labjack/I2C-AppNotes/blob/master/UD_Driver/I2C_Abstraction_Layers/matlab/UD_I2C_Utils.m You should also look at the I2C application note on our website: https://labjack.com/support/app-notes/i2c To perform I2C Operations, you should follow one of the functions, several are defined (you can search for these names in the .m file): read readAndGetAcks write writeAndGetAcks writeAndRead writeGetAcksAndRead There is also one "configure" function that describes what the configurations do. Your code that has multiple "AddRequest" commands and then a "GoOne" command will be slightly more efficient in terms of device I/O as all of the device communications happen when you execute the "GoOne" command. The matlab example uses "ePut" commands that perform device I/O immediately. To summarize what all of the I2C operation functions are doing, they: 1. Do some matlab-stuff for defining and populating arrays. 2. Prepare for an I2C operation by adding a "read" or "write" request. I don't believe you can have multiple write requests stacked up in a row but this might be ok. When getting started I suggest only doing one combination of a single read, a single write, or a write followed by a read. 3. Some of the functions tell the device to keep track of the "ack" bits received from the sensor. I recommend doing this when getting started, you want to make sure this number isn't zero. If it is then you are likely not communicating with the correct slave address or the pull-up resistors on the SDA and SCL lines are either missing or to large/small. 4. Execute the "GoOne" command which tells the device to perform the I2C operation. 5. If required, (when reading data, or checking the number of received acks) read data. Moving on to your specific sensor and supplied code, depending on how you have configured the I2C slave address jumper lines, you need to shift your slave address over by one bit when using the UD driver/U3/U6/UE9 devices. The T7 is different (look at the LJM version of this wrapper in the same .git repo). The UD driver requires a "shifted 7-bit slave address". The UD driver automatically toggles the lowest bit (the read/write bit) to indicate read/write I2C commands. It doesn't automatically shift the 7-bit slave address. You should try writing 32<<1 or 0x20<<1. It looks like this is what "winterv" was doing. You should also add "GoOne" commands in between all of your I2C write commands. Make sure you have installed 4.7k resistors between VS and the SDA/SCL lines. If this doesn't work we (LabJack) highly recommend that you pick up a logic analyzer (you can get them for pretty cheap), they are very useful for debugging digital communication issues. Most have I2C/SPI/UART/1-Wire data interpreters that let you see what data is being written to/read from your connected sensor.

There are some DAQFactory stream examples here: https://labjack.com/support/software/examples/ud/daqfactory "UD" is the library for the U3, U6, and UE9.

I'm thinking he wants to copy/paste from the sequences in various examples to his sequence. I do the same quite often. I open the different examples one at a time, copy/paste the code from different sequences into a text editor, then open my new CTL, and copy/post from the text editor into the new CTL.