Sparse LJM support with DAQFactory

Sorry about the delay.  We are just getting caught up from the long holiday weekend in beautiful Colorado.

We purchased  a T-7 Pro and DAQFactory Pro, to set up data acquisition for a woodstove test lab we are building. We are trying to hook up a Sensirion SDP610 pressure sensor that communicates via I2C. In trying to do it through DAQFactory, we are discovering that the support for T-7 commands such as LJM_eWriteName is not there

Actually eWriteName and eReadName are supported.  See "Script" section here:

https://labjack.com/support/software/examples/ljm/daqfactory

... but that does not solve your problem.  For I2C you need to write and read arrays which you can't do with those functions.  You need something like eNames which is not supported in DAQFactory at this time.

The DAQFactory support for LJM (the library used with the T7) is actually quite slick and simple and powerful, in my opinion.  It is a quite thin layer that simply exposes the power of the register interface used by the T7 and makes it easy to bind DAQFactory with all the registers on the T7.  Some advanced functions such as serial communication, though, require arrays which is not supported by AzeoTech at this time.

Azeotech is saying they are planning to add it in the future, but for now to use their "extern" function to call the Labjack dll directly. I'm not an expert at low level programming by any means, and it is leading down a rabbit hole of data type conflicts, function name conflicts, etc. that are simply too steep a learning curve for my aging brain.

I agree.  Not with "too steep a learning curve for my aging brain", as I'm sure your brain is super powerful, but with the idea that that is an advanced and complex thing to do.  If it winds up being needed we can make an I2C-DF-LJM example, but we would rather support you as you suggest next.

I really like the Lua scripting that is built into the T-7, and the fact that there are some I2C examples as a starting point. Would it be a better idea to set up an startup script on the T-7 to do the I2C communication, write the values to the Modbus registers, and try to communicate with DAQFactory through that route?

Yes, that is a great way to do I2C and something our older devices can't do.  We have lots of I2C examples that read from I2C chips and put the readings in user-ram that can then be read by other clients.  We think that is a great way to handle an I2C sensor and a technique we like to support.  I'll have someone else follow up about making sure you have the latest examples, which example would be best to start from, and then if you need further help we can see about getting an SDP610 here so we can make an example specifically for it.

Or, alternatively, what about downgrading to an older Labjack that has more native support built into DAQFactory?

Myself I prefer the new LJM-DF interface over the older LJM-UD interface.  There are some serial examples for the UD devices, but they are pretty complex.  The T7 script route will make the DF part simple.

Or, hiring it out as a consulting project either to yourselves or to Azeotech?

That is always an option, but at this point we can proceed with our awesome free support to help you get a script going or make a new example script for you.

We have a new version of Kipling on our website that has several new I2C lua scripts that read and write data to/from RAM registers that interface with a variety of I2C sensors that would be a great starting point for you if you want to pursue writing a Lua Script that gets executed on the device and then allows you to simply poll data from the device in DAQFactory if you can't get full I2C support using DAQFactory.  If you don't want to download and install the new version of Kipling/the LJM library the code is also available in the I2C-AppNotes github repository.  We published two things that would be useful for you to look at, a Lua I2C utility (located in the I2C_Abstraction_Layers/lua folder) that aims to make some of the I2C commands easier to understand and use.  There is also a really useful "find_all" function that reports any/all slave addresses that you can communicate with on the I2C bus.  We also have several sensor specific examples that all utilize the I2C utility code.  We don't have an example specifically for the Sensirion SDP610, but we have several available that will hopefully give you a good place to start.  

A good first one to look at is the ADXL345 accelerometer example.  The first 95 lines of code are the I2C Utility, lines 96 -> 100 initialize the utility.  Lines 102-110 search for the slave address and indicate if it was properly detected.  Lines 112 -> 141 configure the sensor, read data from the sensor, and then save the data to user ram registers that can be polled, logged, graphed by simple applications.  

We are still working on transferring and documenting these scripts on our website, but they have been very useful to many customers already and hopefully you find them useful as well.

It looks like the "I2C Search" feature isn't working for your particular sensor or maybe your sensor responds to any and all slave address that gets queried on the I2C bus.  

You may want to avoid using the "find_all" function and stick with the read and write functions.  You can use the value read from executing the function "MB.R(5114, 1)" which is the "get acks" command.  If this value is zero than you likely haven't configured the I2C bus properly or have not wired the I2C sensor properly.