Open teemuatlut opened 5 years ago
yes it's on the board, it goes from the tx pin to the rx pin on the cpu.
You might need to alter the solder serial jumper option on your stepper boards, depends how you have them set. It's caught a lot of people out, including me ;)
Some of my boards of v10, meaning one pin is UART and another pin is NC. Needed to bridge those and I'll see what happens now.
@doggyfan no problem...
The AVR SoftwareSerial is a little worrying, as you say I wonder if it has got worse for some reason? I'm not very familiar with the AVR but I wonder if slowing down the baud rate and allowing interrupts during both the send and receive code would be better? Would have to make sure that the interrupt on change is still disabled though!
Yes the SKR board seems to have hit the "ender 3" price point. Lots of folks seem to be getting them. The Bigtreetech facebook page is awash with folks asking the same questions over and over. I'm amazed at how many folks seem to be happy just to follow some random YouTube video on how to do this stuff, happily installing pretty much anything you tell them to install on a PC, not to mention running stuff that could burn their house down! It's a bit of an eye opener really.
@teemuatlut I've just rebased my changes on your current master, so hopefully the branch TMC2208_PR is up todate now.
One of the nice things about the SKR board is that they have pretty quickly publish a schematic for it on their Bigtreetech github account.
@teemuatlut which driver boards do you have? One slight oddity about the SKR is that it feeds the TX/RX into the pin next to the one marked PDN. On some driver boards this is marked UART I think, but on most NC. The general advice is to bridge the two pins on the driver together. But there is a nice trick that you can do the same thing by installing a jumper at 90 degrees to the normal jumper install under the driver. I think it is the two centre pins of the first two rows. It is easy to work out if you have a meter, just buzz out the header pins against the jumper pins. This probably does not make much sense sorry!
0xC0:0C:00:00
with your branch v0.3.1. Now I'll have to see if my own code worked after all!
I just got the SKR because it was cheap and I'll likely have to troubleshoot with it for a lot of people. I have no intention of using it with any of my printers.
@gloomyandy I had previously fetched your branch and it worked alright. Now after pulling the latest changes, I've got a good DRV_STATUS response (the hex value everyone looks at) but a failed Testing connection = All low
. Most interestingly frustrating.
@teemuatlut on the SKR or AVR board ?
SKR, but it seems to work now. No idea what was wrong minute ago.
@teemuatlut hmm that's strange all fine on my SKR both the DRV_STATUS and the connection test. Tried about 10 M122 and all worked... Will keep an eye on it though!
Seems a bit random actually. I'm getting maybe 60/40 of OK / ALL LOW.
I pushed the master branch online and that get me OK response 100% of time. For me at least. But that still works with just a delay and read while available, so I'd still like to get in the sync bits find.
That is very odd. Could you try increasing replyDelay from 10 to say 20 and see if that makes any difference to your failure rate? What do you have hooked up to the SKR anything that could be generating interrupts? Also although I'm sure you know this do you have the board powered from an external supply? The TMC2208s don't seem to be very happy when running with board using USB power.
The board is powered by USB but there's 12V power of course for the drivers. Increased to 30. Seemed to be a bit more reliable but still has issues.
Switched to Internal 5V line and errors increased. I sent 5x M122 in quick succession and 4 had ALL LOW error.
Is that all low on just one driver or multiple drivers? How many drivers do you have configured (I have all 5, I wonder if that makes any difference?). I can do M122 after M122 with no errors at all, really strange.
Just one.
https://github.com/teemuatlut/TMCStepper/compare/tmc2208_find_sync Here's my development branch for this thing and it seems to work alright. Probably due to the delay after writing as a low value on that seems to upset the board. Maybe the final answer is something in between the two.
If you want to refine your own branch, you can see that you don't need to add anything to gain access to TMC2208_SYNC or addr, as those are already passed as part of the datagram.
Could you try adding a delay at say the end of _sendDatagram in my version to see if that makes it work reliably? No problem if you can't as I can test it later tonight. If that does make it work I wonder if that tells us anything about the need for a delay in the write code?
But I'd be happy to go with your version of the code if you are happy with it?
I wonder if this version works any better on the AVR with software serial for @doggyfan ?
I did think about doing that, but I wanted to keep the code not making assumptions about the data it is sending. But I guess if we are going to go that way we may want to get rid of the length parameter and just have the code expect to have a fixed format packet. But I don't suppose it matters really.
Ok just tried with a single driver and with my code I get errors about 50% of the time. I added a 1mS delay at the end of _sendDatagram and sure enough back to working 100%.
I think I did mention above that changing the timing of things may have unexpected consequences!
Yea I can verify that on my end. I'll start working from your code base and bring it a bit closer to what I had. Hopefully without breaking anything.
I'm just doing some testing with your current code now. Seems pretty good so far.
Does that code work OK on the AVR, both hardware and software?
I'll need to check again since there have been so many changes since.
https://github.com/teemuatlut/TMCStepper/tree/serial_sync
Reverse log of gloomyandy/TMC2208_PR..HEAD Reverse is a bit easier to follow if you want to see the thought process behind every step.
Hmm that looks to me as if it could end up stuck in the read 5 bytes loop forever if for some reason the TMC2208 does not send the remaining 5 bytes (or more likely the UART misses one or more). Also are the delays of 10mS really needed? I found a delay of 1mS worked fine for me?
I ran a couple of prints with your previous code (this one https://github.com/teemuatlut/TMCStepper/tree/tmc2208_find_sync) on my SKR with no problems. In some ways I prefer this version. It preserved the timing of the code that has been out there for some time, but hopefully fixes the issues we have been seeing.
The delay of 10ms is conservative at this stage and I haven't tweaked it at all yet. The previous code didn't have the abort timing in effect; the code is commented out. There's also a bug in the sync bitmask. 0xFFFFF is just 20b when we should be looking for 3 bytes / 24b. EDIT: Though it likely didn't matter as the first nibble would be 0, from 0x05.
I'll add the same timeout abort code to the second loop aswell.
The previous code doesn't really need the abort timing though. It has the fixed delay at the start after which all of the data should be sat in the read buffer. Which is pretty much what the old code used to do. However it does need to add a test on the reply from the read if it is ever < 0 then abort with no data found. So something like....
while (serPtr.available() > 0) serPtr.read(); // Flush
for(int i=0; i<=len; i++) serPtr.write(datagram[i]);
// Wait for response to be sent and read into UART buffer
delay(replyDelay);
const uint32_t sync_target = (((uint32_t)datagram[0] & 0x0F)<<16) | 0xFF00 | datagram[2];
uint32_t sync = 0;
do { // Find SYNC nibble and the rest of the pattern
int16_t res = serPtr.read();
// end of data with no sync? Abort
if (res < 0) return 0;
sync <<= 8;
sync |= res & 0xFF;
sync &= 0xFFFFFF;
} while ((sync) != sync_target);
uint64_t out = sync;
// Read data bytes and CRC
for(uint8_t i = 0; i<5; i++) {
int16_t res = serPtr.read();
// not enough data after sync? Abort.
if (res < 0) return 0;
out <<= 8;
out |= res&0xFF;
}
return out;
I thought your use of the short mask was deliberate! The first byte of the datagram does not have to be just TMC2208_SYNC it can have data in the low nibble (and perhaps it should to make the sent data different to the expected receive data?). In the above code I have masked out that nibble when setting the target. Note I've not tested the code above!
I tried returning with negative response bytes but it broke the implementation.
I've pushed the most recent commits and I've also reverted back into my mistake of 20b bitmask as it actually makes sense after all. The current code seems really stable and reliable so if it works with AVR, I'll merge it into the next release. I'm definitely not going to spend another day on this =)
I tried returning with negative response bytes but it broke the implementation.
That's a little worrying, was that with the fixed length initial delay, rather than doing the timeout stuff? The two sort of go together. I wonder if in this case the initial delay (replyDelay) is sometimes just not long enough? At 5mS it is certainly pretty marginal for the LPC176x software serial code.
As to the mask it would really be better to mask the bits when you initialize sync_target and use the full 24bit mask later. In a response the first byte should always be TMC2208_SYNC anything else is an error.
I see you have moved the "extra" delay out into the read routine (which I guess match the one in the write). I suspect that using replyDelay may be a little excessive, but who knows!
Let me know when you are happy with the code and I'll grab a copy and give it a try.
I think it's close to ready now. I increased replyDelay back to 5 as it made the AVR SW UART happier.
I see your point on bitmask.
OK, will give it a try....
Hello, not that you want to hear from someone without the ability to help with the development side, but I did want to report that I have non-working TMC2208's on AVR for a while and never reported a bug in the Marlin forums as I had no way to really determine where the problem is. I have (2) AVR machines that have the communications issue. I am only reporting this because when this thread started, it was mentioned that no one was reporting it in the Marling forums. :)
Fortunately for me, I just use my printers for fun and I have been way too busy lately to worry about them not working. To that end I just lurk around the forums and watch all the conversations.
Thanks and keep up the good work! I hope to see a permanent fix soon.
-William
I'd rather hear about it than for something to go unnoticed. But the default answer for communication issues is to check the wiring and configuration. A fundamental issue on the library level would very likely cause many more people to speak up. The good/bad thing about the TMC2208 drivers in particular is that they "work" even if you don't have UART communication working to and from the driver.
If you want, you can try the serial_sync
branch, but I'm planning to make a new release today that includes the changes. Other than that it's back to Marlin troubleshooting bullet points.
But I know the new code works and there should be no reason for it to not work for others as well.
Just to confirm I've been running the serial_sync branch for the last day or so and have happily completed several prints from the SD card and via Octoprint. My version of Marlin is modified to enable MONITOR_DRIVER_STATUS when using software serial so it will have been generating a fair number of read/writes. I've added additional logging to check for CRC errors etc. and have seen none at all.
Oh should have said all of that on an SKR V1.3 board with five active TMC2208s.
The trouble is, most people are going to stay firmly fixed in the 8-bit world, which means using a (a currently) troublesome software serial driver for them :(
A spare timer (to create timed ints) on the AVR (or hanging off a used one) would be a very useful to fix the AVR software serial driver.
I tested the branch with AVR SW UART as well.
@doggyfan Have you had chance to test this latest branch (with extra logging)? I'm curious as to how bad it is and how it compares with the previous state.
When I say previous I mean whatever the one was that was a "working" version on that platform.
You're determined to keep me in 8-bit mode aren't you @gloomyandy lol
I'll check in the next hour or, just resting my poorly back at mo.
Right den. This is boot-up on the AVR. I've added a retry loop (up to 9 times if need be) as the AVR is trouble some.
hmmmm. With the latest and not so greatest Marlin I get this from an M112. No idea why and totally no feedback as to why from the AVR board (user should ALWAYS be told why it's killed itself). It's OK on the SKR 1.3 board though.
On the AVR LCD it just says ..
KILLED
PRINTER HALTED
Please reset
03:43: M112
ok
Error:Printer halted. kill() called!
M112 is emergency stop
oops !
AVR M122 lol ..
a fair few retries to overcome the software serial problem.
But the serial sync'ing certainly works no problem at all. It's always best to use it, that's what TMC has put the sync byte(s) in for.
32-bit (SKR board) is perfect though, never an error in sight. Now if only we could get everyone to go 32-bit.
Another AVR M122 ..
What code where you using for testing? If the code was as bad your log would suggest, I should been seeing a whole lot more failed connection tests.
Your serial_sync code and the current Marlin code.
Your current serial sync with added debug code ..
I want to swap over to TMC5160's and use SPI to do constant stepper monitoring all the time but they are somewhat costly at the moment. But TMC2208's on the 32-bit do it for me at the moment.
Here's mine with no modifications done. There are a few failed attempts but it's not as bad as was in your log. You can also see that even with the failed reads, there's still a successful test connection
, which essentially calls DRV_STATUS
again and compares it to invalid values.
After this I again called M122
thirty times and all had successful reads on both the hex value as well as test connection.
It might depend on the configuration of Marlin as a whole (how resource stretched the ISR's are maybe), I don't know, I can only report back with what I get.
How do you make your text colapsable like that on these github messages ? (your last M122 output)
I'll that in future as it saves the reader having to scroll through all the text.
Documenting here for others to see.
There seems to be some connection issues with TMC2208 with at least AVR and DUE platforms. The likely commit to cause the issues is d27257900a14ee8cd8df7d5c9b01f1f60c3c4d0b. @gloomyandy Any thoughts? I'll try reverting things bit by bit and see what the offending line is but I'll have to revert at least some of your PR and make a bugfix release.
Current solution is to use v0.3.1 until the issue is fixed.