Closed wolfstrassen closed 8 months ago
sphawes
commented
8 months ago awesome, thank you so much for the detailed report @wolfstrassen, and im sorry for the long delay! I thought i found a workable solution by just allowing a delay in Gcode with G4 but this is a much better solution. ill work on integrating this into the next release.
sphawes
commented
8 months ago alright i tested this config and it's working well. CONNECT_COMMAND contains:
M260 A112 B1 S1 ; Selecting VAC1 through the I2C multiplexer
M260 A109 ; Starts Command to VAC sensor at address 109
M260 B48 ; Address Byte 48 selects CMD register
M260 B27 ; Sends byte to select 62.5 sleep time, SCO, sleep mode conversion (0001 1 011)
M260 S1 ; Sends data
M260 A112 B2 S1 ; Selecting VAC2 through the I2C multiplexer
M260 A109 ; Starts Command to VAC sensor at address 109
M260 B48 ; Address Byte 48 selects CMD register
M260 B27 ; Sends byte to select 62.5 sleep time, SCO, sleep mode conversion (0001 1 011)
M260 S1 ; Sends dataThen VAC1 ACTUATOR_READ_COMMAND is:
M260 A112 B1 S1 ; Select vac1 through multiplexer
M260 A109 B6 S1 ; Selects MSB register
M261 A109 B1 S2 ; Request one byte back via decimalAnd VAC2 ACTUATOR_READ_COMMAND is:
M260 A112 B2 S1 ; Select vac2 through multiplexer
M260 A109 B6 S1 ; Selects MSB register
M261 A109 B1 S2 ; Request one byte back via decimalAnd i get great granularity even with an N045 nozzle tip, plus readings aren't delayed. Thank you so much for the notes @wolfstrassen!
wolfstrassen
commented
8 months ago Glad to be helpfull. Just one note. I had to use two bytes and signed data, because where the office is located, the "resting" value of the sensor is really close to 0, so depending on climate conditions, sometimes is like 254-255 and sometimes 0-1. So sign was a necesity.
This happens because the readout of the sensor is signed, and the MSB is being used as an usigned integer. I'll mark this as closed tough since that is a separate issue
Version Number
3.0.5
Bugfix or Enhancement
bugfix
Description
Wasn't sure to post this issue here or in the docs since the problematic GCODE is on the docs github, but here it goes:
Currently measures are delayed by one reading, this can be replicated by the following procedure
This demostrates that the readings are delayed by one. It's my guess that the reading takes place before the 20 ms that are required in the datasheet to complete the conversion, but using a G4 20 delay between the start of the measurements and the reading on the GCODE driver did not fix the issue
Attached there is a video showing the issue Is worth nothing that the values have sign because I'm using two bytes instead of one on the read gcode, but the issue also presents when using only one. (Sound on to listen to the pump)
https://github.com/opulo-inc/lumenpnp/assets/57505218/e49cc942-4734-4bd5-b27b-608d51a3f4d2
This sometimes causes issues with the part detection
Suggested Solution
Changing the sensor so it reads all the time fixes this. This can be done by changing the actuator read command to the following
M260 A112 B1 S1 M260 A109 M260 B48 M260 B27 M260 S1 M260 A109 B6 S1 M261 A109 B2 S2
The line that is important is M260 B27, this set the sleep time between samples to 62.5 ms and starts a sleep mode conversion which makes the sensor continously refresh the data. Ideally this should be on the connection GCODE so we can just do the readout part on the read command, but with my testing, there were some issues that I was not willing to deal with right now
The last line M261 A109 B2 S2 is to read two bytes instead of one the sensor has a 24 bit readout, but M261 does not have an option for 3 bytes values (S2 only work for single and two byte return values, and did not want to parse a byte array). This last part is not neccesary, but I think that 1 byte is not enough for fine-tuning