Duet sometimes really slow? - I2C error or?

dc42

@martin1454 said in Duet sometimes really slow? - I2C error or?:

One thing I have been thinking about - When the discussed error occurs, only 1 in maybe a 100 commands gets sent sucessfully through the I2C interface, and the rest is lost/ tries again, and that's why it is so slow.

I was under the impression that when the problem occurs, no I2C commands get through at all. Do you have any evidence that any I2C commands are getting through? I2C commands are needed to set the fan RPM and to read the endstops. They are not needed to drive the motors or the heaters.

I think the reason it is slow is that the processor is spending too much time trying to send data through the I2C interface and/or servicing the interrupt from the DueX5 that indicates that an endstop input has been changed.

Would it be possible (in future update) to check if I2C errors are accumulating, and in case of - try to reset / reinitiate the I2C interface in the SW of the duet? I know there is no connection to the reset pin of the SX1509B, but mabye by reinitiating the I2C interface of the duet, it could get out of the mode?

I have it on my list to see whether something along those lines could be done, but unfortunately the I2C specification assumes that errors do not occur and makes no provision for recovering from a protocol error. If the SX1509B gets into a state in which it does not recognise a start bit followed by its own address, it may be that nothing except a hardware reset can get it out of that state. I can try sending several stop bits first.

dragonn

maybe at boot the SX1509B needs a lite bit more time too 'initialize' before sending the first I2C command? Just my idea since most of the time the problem as I read happens only at boot.

Martin1454

@dc42 said in Duet sometimes really slow? - I2C error or?:

@martin1454 said in Duet sometimes really slow? - I2C error or?:

One thing I have been thinking about - When the discussed error occurs, only 1 in maybe a 100 commands gets sent sucessfully through the I2C interface, and the rest is lost/ tries again, and that's why it is so slow.

I was under the impression that when the problem occurs, no I2C commands get through at all. Do you have any evidence that any I2C commands are getting through? I2C commands are needed to set the fan RPM and to read the endstops. They are not needed to drive the motors or the heaters.

Yeah I just remembered that the motors don't use the I2C interface, so yeah there is a possibility there gets no communication through - disregard my previous message.

EDIT: it looks like there is a "RESET" signal on the large ribbon cable - If there will be a duet wifi 0.9, mabye connect the reset to the SX1509B reset pin so it would be possible for the MCU to reset it.

GizmotronX5000

I was under the impression that when the problem occurs, no I2C commands get through at all. Do you have any evidence that any I2C commands are getting through? I2C commands are needed to set the fan RPM and to read the endstops. They are not needed to drive the motors or the heaters.

When I get this error, everything still works, including Duex5 endstops for homing. I haven't tried changing fan RPM during this error though.

dc42

@gizmotronx5000 said in Duet sometimes really slow? - I2C error or?:

I was under the impression that when the problem occurs, no I2C commands get through at all. Do you have any evidence that any I2C commands are getting through? I2C commands are needed to set the fan RPM and to read the endstops. They are not needed to drive the motors or the heaters.

When I get this error, everything still works, including Duex5 endstops for homing. I haven't tried changing fan RPM during this error though.

That's very interesting, because if there was a total breakdown in I2C communication then the endstops should stop working. Next time it happens, please can you pause the print and then:

Send M122 to get the I2C error counts.
Toggle the DueX5 endstops and check whether the Duet can see the changes.
Send M122 to get the error counts again. [When you toggle a DueX5 endstop, it sends an interrupt to the Duet, which uses I2C to read the new states.]
Send some M106 commands to alter the state of fans/LEDs connected to the DueX5 fan outputs, and see if that works.
Send M122 and get the I2C error counts again.
Also send M122 a few more times, to see if when the machine is idle and no endstops are changing, the I2C error count goes on increasing.

GizmotronX5000

@dc42 Can do. It doesn't happen often, but the next time it occurs I'll be sure to reply here with that information.

TBS

Here is my short update:
I have updated to 2.02. The error has recurred. This time again at the start of printing.

dc42

@tbs said in Duet sometimes really slow? - I2C error or?:

Here is my short update:
I have updated to 2.02. The error has recurred. This time again at the start of printing.

Thanks, please see my post addressed to @GizmotronX5000 for useful (to me) tests you can do when this problem occurs.

deckingman

I've just had this slow down happen mid print - first time for me - it's only ever happened at first boot until now,. The only thing I have not yet done is DC42s suggestion of fitting resistors which was mentioned in another thread.

The manifestation is that the printer carries out one or 2 moves, then pauses for several seconds before continuing. M122 shows I2C nak errors 0, send timeouts 34803, receive timeouts 0, finish timeouts 34803. Also reported were:

"Warning: motor phase A may be disconnected reported by driver(s) 5 7" (Never seen that before).

I have the full M122 report if there is any other info that might be needed.

I've sent M106 Pn H-1 to a few of the fans connected to the Duex5 then tried a few M106 Pnn Snnn commands with no reaction on the fans themselves. So, I guess that means a total breakdown in I2C comms?

I've taken a video of what happens with the printer. I've cancelled the print but I'll leave it in this state for a few hours in case anyone wants me to do any tests or provide any more information.

dc42

@deckingman, thanks for keeping your machine on. Please see my response to @GizmotronX500 a few posts back and run the tests there.

deckingman

@dc42 said in Duet sometimes really slow? - I2C error or?:

@deckingman, thanks for keeping your machine on. Please see my response to @GizmotronX500 a few posts back and run the tests there.

Yes tried that. As I said, the fans are all configured as thermostatic so I tried sending M106 Pn H-1 first, then a few M106 Pnn Snnn commands and nothing happened as far as the fans were concerned.

I don't have any Duex end stops configured so I can't test them. That's not strictly true. I do have micro switches connected to E2 and E3 but no axes configured to use those switches....... Just tried toggling those switches but the status on machine properties page remains unchanged.

So I'm guess that I2C comms have completely stopped in my case. M122 now reports I2C send and finish timeouts as 1861859.

I'll leave the printer powered up for a while yet.

dc42

@deckingman, thanks. What were the results of #3 and #6? I'd like to know whether the I2C error count increases (a) continuously, (b) [if not continuously] when you try to change the speed of a DueX fan, (c) [if not continuously] when you toggle the state of a DueX endstop switch.

deckingman

@dc42 said in Duet sometimes really slow? - I2C error or?:

@deckingman, thanks. What were the results of #3 and #6? I'd like to know whether the I2C error count increases (a) continuously, (b) [if not continuously] when you try to change the speed of a DueX fan, (c) [if not continuously] when you toggle the state of a DueX endstop switch.

Damm. Sorry I didn't pay enough attention to what you were asking. The only info I have is that when I did the first M122 during the print, the send timeouts were 34803 and some time later, they were 1861859 which isn't much use to you. I turned the printer off before I went to bed last night and of course, the bloody thing is behaving itself again now.

I'll pay more attention next time it happens.

dc42

@deckingman, if they went up that much then I suspect they were continuously incrementing.

What I suspect happened is that the interrupt signal from the SX1509B on the DueX went high, indicating a change in an endstop input signal (real or imagined). That causes the Duet main processor to try to read the SX1509B input registers, which will also make the interrupt signal go away. But if I2C communication with the SX1509B has broken down, the interrupt won't go away and the Duet will keep trying to read it - which accounts for the slowdown.

deckingman

@dc42 Cheers. I'm just in the process of making up a plug with the resistors you mentioned elsewhere. I'll try that and I'll replace the ribbon cable between the Duet and Duex5 as well. Open to any other suggestions.

dc42

@deckingman said in Duet sometimes really slow? - I2C error or?:

@dc42 Cheers. I'm just in the process of making up a plug with the resistors you mentioned elsewhere. I'll try that and I'll replace the ribbon cable between the Duet and Duex5 as well. Open to any other suggestions.

Please try just the resistors. The ribbon cable is unlikely to be the problem, and I'd like to know whether the resistors fix it.

deckingman

@dc42 said in Duet sometimes really slow? - I2C error or?:

@deckingman said in Duet sometimes really slow? - I2C error or?:

@dc42 Cheers. I'm just in the process of making up a plug with the resistors you mentioned elsewhere. I'll try that and I'll replace the ribbon cable between the Duet and Duex5 as well. Open to any other suggestions.

Please try just the resistors. The ribbon cable is unlikey to be the problem, and I'd like to know whether the resistors fix it.

Sure thing - will do.

Martin1454

I will try the next time it occurs to plug on my logic analyzer and see what I can see.

deckingman

@dc42

Had to improvise a bit (as well as make allowances for my failing eye site and shaky hands ) but it'll do the job. The resistors are 1.8K so pretty much in the middle of the range you specified. We'll see what happens....

Interestingly enough, now that the machine is not in an error state, those switches that are connected to the Duex End stops do now respond, even though the axes they were originally assigned to are no longer configured - (I guess you knew that though).

deckingman

@dc42,

David. As I'm waiting for some filament to arrive, the machine is just sitting here idle. Is there anything I can do to attempt to provoke the misbehaviour? I was thinking along the lines of writing a little script that would generate a gcode file that simply toggled one of the duex5 fans on and off. Or may send multiple M260 commands. Is there any point in me doing that?