I think there is definitely something wrong with RC8

[ruggb]

the first print shifted about 3mm x axis at maybe layer 4. the rest printed ok. now I cant get it to the skirt. It bombs and says error initializing SD - there is no SD card inserted. reloaded fa6bf12 and it is working fine core XY build 9b55159

[Bob-the-Kuhn]

Have you tried the latest RCBugFix?

The one you used (9b55159) was created 27 days ago. This issue may have been fixed.

[ghost]

Check your X axis for tightness. The SD card issue... Check LCD cables and interface board (if you have one).

[ghost]

But, yeah. There's a few things wrong with RC8. That's why there's RCBugFix.

[ruggb]

@Bob-the-Kuhn =9b55159 used was the latest up until 8 hours ago. @Tannoo =if the printer can't even get to print the skirt and works fine with a previous version, why would you even THINK that there was a problem with my x axis DUH! and those versions ARE bugfixes. I lose all confidence with comments like those.

[ghost]

Shifting the X axis caused by mechanical errors can be random and may not happen on every print regardless of the firmware used. This can also be true for the Y axis. You have two different issues. So, uhm... What's wrong with my comment?

[ruggb]

Well, I guess if I had not stated that it totally bombed out on the next print, that the previous version was reloaded then printed totally without incident, and that there are a number of issues posted RE RC8, that would be a logical comment. In fact the first thing I did while it was still printing the mess was to check my drive system, and should have stated that. Then again, you don't know me and are not here watching it print so you have no idea -- BUT if you add to the comment things that indicate you are not aware of the fact that those two builds are bugfixes, I get suspicious that your purpose is to defend the build rather than determine if there is a problem. AND I am aware that there will always be a "few" things wrong with anything humans build, including software. I am a retired EE and have been there, done that - many times. -- on to the next build - at least I think I have figured out how to migrate most of my settings.

[3dGriff]

@ruggb are you still having issues with this? I haven't quite had the time to figure out why, but I get the sense that a few of our development machines run harder or faster on RC8. This seems to be related to the stepper motors being different on these machines. I have dialed back the movement and acceleration speeds on these machines to compensate.

Have you tried reducing speed, I have no input on the SD issue, but I can say I had belt slippage and missed steps with previously stable movement settings. Just a thought.

Additionally, I see that you are using CORE XY, there is a separate issue #5776 regarding temperature with an unverified suggested connection to defining CORE XY. This is unverified, however, the user reported their temperature issue was resolved by commenting CORE XY and uncommenting CORE YX. I'm not sure if this helps but I think it's worth mentioning.

[ruggb]

I dumped that build and ran the RC7 I had. I am moving to the latest build but have not run it yet. The issue I was having may relate to steppers. It seemed like the RC8 was running slower than I expected and when I put RC7 back it seemed to run faster. But then apparently some steps were lost in RC8 and the print shifted about 2-3mm to the left. Then on the 2nd try it started to print and never made it to the bed start position. I have had belt slippage issues and the first thing I put my hands on when I saw that was the belts. No problem there and it would have shown something in the past or after I reinstalled RC7. RC7 worked fine with no changes-just reloaded - same print, same Repetier. I may have repositioned the print on the bed for hairspray reasons. I am not sure what temp issues you are referring to. If it is motor temp, I never checked that. If it is hotend temp, the print did not exhibit that issue.

What is the diff between XY and YX? Mine is set at XY. Does it just swap the axis?

I set the code to tell it that the config and other files I was using are from my previous version. This is the first time I did that so there may be an issue there. I am going to check it on the new load b4 I try it. I have changed the config files, the language file, the ultralcd files, and the version file. But they are the same as my RC7 = though I did notice a large diff in the ultralcd file code and I made the mod to the new files. The back to status screen timeout of the babystepping function does not happen anymore. @Roxy-3D has verified that on his her system and it is not modified like mine.

[thinkyhead]

Keep working to narrow down a repeatable case. This will make it easier to locate the specific cause.

[Bob-the-Kuhn]

I've heard of USB comm problems screwing up prints. Ruining prints or stopping prints I've heard of but shifting the whole print over by 2-3mm doesn't seem like it fits that scenario.

Have you tried printing from the SD card? I've had to go that route.

By any chance was the room noticeably warmer/cooler during the good prints vs. the bad prints?

There was some mention of loosing steps. How many steps would it take to shift it by 2-3mm?

RC8 release notes talk about adding a minimum step pulse width. I measured the RC7 & RC8 default step pulses. Both came in at 8-10uS so that's not a concern.

Long shot - maybe the stepper motor current is marginal. You could try increasing it a bit.

[ruggb]

thx bob == but if there was a USB comm issue it would affect RC7 also. I have never had a comm issue, but a firmware one that mimicked it because the firmware couldn't handle the print speed.

No, the final persistent error was that it could not initialize the SD card.

No noticeable temp diff, but I didn't check the motors. Why would RC8 heat the motors more than RC7??

It is 200 steps/mm, so about 600. Once it missed those steps going in the x direction then the whole print shifts.

Why would stepper motor current affect RC8 and not RC7? Especially if the PW is not lower. I just tried the latest build. I had to kill it right at the beginning - not a fw issue - but when it went to the park position it became totally lost.

If I reset it - emerg reset on repetier or with the Ramps reset- it will run b4 I home all. Not a nice sound when it hits the stops. I don't think that is a design feature. I can't remember, but didn't RC7 refuse to run until it was homed?

I am going to review the config and see if this migration idea actually works. I will also remove my ultralcd mod, but I don't believe that is an issue.

These are my stepper settings

/**
 * Default Max Acceleration (change/s) change = mm/s
 * Override with M201
 *
 * Maximum start speed for accelerated moves: { X, Y, Z, E }
 */
#define DEFAULT_MAX_ACCELERATION      {9000,9000,100,12000}    //** X, Y, Z, E maximum start speed for accelerated

/**
 * Default Acceleration (change/s) change = mm/s
 * Override with M204
 *
 *   M204 P    Acceleration
 *   M204 R    Retract Acceleration
 *   M204 T    Travel Acceleration
 */
#define DEFAULT_ACCELERATION          5000    //** X, Y, Z and E acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  12000    //** E acceleration in mm/s^2 for retracts
#define DEFAULT_TRAVEL_ACCELERATION   9000    //** X, Y, Z acceleration in mm/s^2 for travel (non printing) moves

/**
 * Default Jerk (mm/s)
 *
 * "Jerk" specifies the minimum speed change that requires acceleration.
 * When changing speed and direction, if the difference is less than the
 * value set here, it may happen instantaneously.
 */
#define DEFAULT_XJERK                 20.0
#define DEFAULT_YJERK                 20.0
#define DEFAULT_ZJERK                  0.4
#define DEFAULT_EJERK                  100.0 //**

[ruggb]

I am doing my optical compare on CONFIG....h

I believe my endstops are "interrupt capable" but this statement would be better it you stated what YOU mean by that.

// Enable this feature if all enabled endstop pins are interrupt-capable.
// This will remove the need to poll the interrupt pins, saving many CPU cycles.
#define ENDSTOP_INTERRUPTS_FEATURE

They go thru a Ramps 1.4 board to an Arduino mega2560? They are active low. So I assume that feature depends on the processor and if YOU program it to be an interrupt. So you should be able to determine that based on the motherboard selection.

That is the only diff in my config - I enabled it. I'll see how it works.

NOW CONFIG...adv.h

If one defines DUAL_XCARRIAGE, it doesn't appear that the DXC variables are defined? I don't use it, just an observation.

Everything else looks the same.

[Bob-the-Kuhn]

You're an old time bit banger like me. You've run into marginal systems where the behavior was hard to explain until the real culprit was found. Very frustrating. Broke is a whole lot easier to fix.

I'm at a loss on the print problems. In situations like this I tend to get a good night's sleep and then assume everything is broken until proven otherwise.

Are you also having SD card issues? Sounds like you're running a Mega2560 RAMPS system. On those systems, strange SD card behavior is usually traced to cable placement.

[ghost]

@ruggb, ensure the proper MB is selected in Configuration.h. This is one setting that could throw everything off.

I say that because you have too many weird issues happening. I have run many different iterations of Marlin without having issues like you are having.

That is to say that you have ONE setting off. There could very well be multiple issues happening. Have you checked your power supply voltage? And how about the 5V rail? There might be voltage swings that can cause havoc also.

Chew me out if you like.... I'm only offering suggestions (mainly the K.I.S.S. method) as it seems that this has not been resolved yet.

[ruggb]

The same MB as in RC7. After as many migrations that I have done, I get that right.

RC7 works. I have a 40A supply. Does RC8 draw more than that?

I repeat, I have no trouble with RC7 so why are you trying to point to my hardware -- OH YEAH, you are SW engineers. Got it.

OK, I am abandoning RC8, when does RC9 come out.

This thing gets lost doing my manual bed leveling.

I have the endstops set for interrupts but it started from 305,0 and tried to go to 305,305 and stalled 4/5 of the way there after about 6 rounds of going there, then banged the stops at 305,305. No endstops there. They are at 0,0,0

From the looks of the issues, you broke something.

[Bob-the-Kuhn]

ENDSTOP_INTERRUPTS_FEATURE

Some of the 2560 pins can be programmed to cause an interrupt when they change state. That's why almost all of the endstops are assigned to these pins: 0,2,3,10,11,12,13,14,15,18,19,20,21,50,51,52,53,62,63,64,65,66,67,68,69

All the interrupt programming/setup is done by Marlin so we don't have to worry about it.

Yes, different processors have different pins that are interrupt capable.

I don't see that this feature buys you anything observable unless you're running with endstops always active and if your CPU is close to being max'd out. How do you tell if your CPU is near its limit? Jerky motion of the steppers is one item I've heard about. High step rates is one reason for CPU loading. Marlin is limited to about 8k steps per second.

---

I keep forgetting to mention turning on the debugging messages.

Issuing a M111 Sxx command will get you additional info on what the machine is doing. The options are:

  DEBUG_NONE          = 0
  DEBUG_ECHO          = 1 ///< Echo commands in order as they are processed
  DEBUG_INFO          = 2 ///< Print messages for code that has debug output
  DEBUG_DRYRUN        = 8 ///< Ignore temperature setting and E movement commands
  DEBUG_LEVELING      = 32 ///< Print detailed output for homing and leveling

M111 S3 will get you both DEBUG_ECHO & DEBUG_INFO activated.

I could see where the DEBUG_ECHO function would slow a print down.

[Bob-the-Kuhn]

When does RC9 come out? All I can tell you is that RCBugFix is the latest code base. Aren't you already running that?

[ghost]

I don't believe that there is going to be an RC9. @Bob-the-Kuhn, that debug info....That gives me an idea on the filament change issue I've been chasing. Thank you for that.

[Roxy-3D]

I don't believe that there is going to be an RC9.

We all want RC-8 to be the last one!!! My bet is we don't have an RC-9.

that debug info....That gives me an idea on the filament change issue I've been chasing. Thank you for that.

Yeah... We need to add a bunch of SERIAL_ECHO() print outs to figure out just what is going on! The good news is a half dozen of them in a 30 line area will figure it out.

[ghost]

I am not a software engineer. I AM in the support industry, however. Often, the simple things are overlooked.

[Bob-the-Kuhn]

Personally, I'm good at missing the obvious.

[ruggb]

Well we are 2-of-a-kind @Bob-the-Kuhn. Unless something major was wrong, I think I found my issue - I totally missed the change to #defines for the endstops. The latest RC8BF 493e738 seems to be working. I think I can close this

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.