read "M260 Amm Rnn" into variable?

o_lampe

I can succesfully send 3 bytes to an ArduinoDue and also receive an answer. I also tried ESP32, but got compiler-errors. (Not a concern for the Duet team.)
But it sucks, that I can't express the data in HEX. (only the address is possible in HEX)
Another thing unclear: are pullups activated on TWCK and TWD0?

o_lampe

@o_lampe said in read "M260 Amm Rnn" into variable?:

can receive an answer.

That answer only appears in the console, but I can't read it into a variable. What is an I2C-read function good for, when you can't work with it?
How do we read sensor values coming from serial, I2C or SPI into a variable?

dc42

@o_lampe, is it just 1 byte that you need to read in a single M260 command, or multiple bytes?

o_lampe

@dc42
One byte would be a starting point, but I'm looking for a more general solution. The barometric sensor I have in mind has a resolution of 24bit.
It seems, if I have a sensor which isn't predefined in RRF, I can only use M308 Y-types like 'linear-analog' or 'drivers'
(no further details in the Wiki about the resolution of the linear-analog, or any info about the drivers-type?)
I could use the 12-bit DAC of the ArduinoDue to send info back to the Duet. That seems easier than trying to store the M260 return value(s) to a variable.

dc42

@o_lampe, which baro sensor is it?

o_lampe

@dc42
I want to start with the GY-63 (MS5611) module, but here
we've discussed other candidates as well. Other candidate is 'NBPLANN150PAUNV '.
They all have a digital interface. A new sensor type, I wish we could define as user in RRF. It's hard to build a 'proof of concept', when we don't have a way to talk with them.

o_lampe

@o_lampe said in read "M260 Amm Rnn" into variable?:

I could use the 12-bit DAC of the ArduinoDue to send info back to the Duet. That seems easier than trying to store the M260 return value(s) to a variable.

~~It seems to work,~~ but I'm a bit confused about the decimal point. Still don't know what the AD-conversion resolution of the Zprobe.in pin is?
As shown, I sent '255:255:255' to the Due and the answer is scaled down to 255.

I wish, I had some equipment to test the latency from

sending 3 bytes over I2C
convert to analog in the Due
Zprobe.in shows the new value

Here's the Due file, if anyone is eager to test it:
Due_I2C_Slave_analogOut.txt

//edit
The sensor reading seems to toggle between 0.6 and 254.9. No readings in between. Seems, the DA conversion isn't a real analog thing. Maybe try the real DAC-output of the Due instead...

dc42

@o_lampe said in read "M260 Amm Rnn" into variable?:

@dc42
I want to start with the GY-63 (MS5611) module, but here
we've discussed other candidates as well. Other candidate is 'NBPLANN150PAUNV '.
They all have a digital interface. A new sensor type, I wish we could define as user in RRF. It's hard to build a 'proof of concept', when we don't have a way to talk with them.

Have you considered the BMP280, https://www.adafruit.com/product/2651? We've had other interest in using this, so we may write a driver for it.

Edit: looks like the BMP388 is even better, https://www.adafruit.com/product/3966.

o_lampe

@dc42
Will look at it, thanks for supporting this idea.
The analog datatransfer is a bit messy,
I get different results from filtered reading vs unfiltered and the DAC output is again different. (real AC with neg. amplitude?)

o_lampe

@dc42 said in read "M260 Amm Rnn" into variable?:

so we may write a driver for it.

I agree, writing a init-rotine for a sensor and support all the features it has, is not beginners-stuff. But it would be nice to have a generic digital type of sensor we could use for our own implementations.

o_lampe

@dc42
would it be possible to use the 'result' function for reading the returned value? Right now it only reports the outcome of a command, but not a read value.

set var.return_value = result (M260 An R3)

JD

@o_lampe @dc42
Just adding that I would also like to see a general I2C read response parser or variable assignment that we can use for conditions in meta command programming. For instance, we have an I2C realtime clock calendar IC attached to a Duet2. We would like to use it to trigger g-codes at certain times of the day.

Currently, we use the http interface to send an I2C command to program the current time of day and an alarm time in to the RTCC IC. Then we use a single alarm interrupt output pin from a single RTCC IC to trigger an endstop input that runs a triggerX.g file and we put our gcode commands in the trigger gcode file. This method is limited to the one time of day.
If we were able to arbitrarily query the TOD from the rtcc from gcode running standalone (no web,telnet,panel etc) we could develop some more useful gcodes.

We also see some utility for some other i2c devices

JD

dc42

@jd I've added this to the firmware wish lit for consideration in RRF 3.5.

jay_s_uk

@dc42 any chance of the current 3.5 wishlist being made available?