Error XD2455 repeating

I have a one-month-old Creality K2 printer and I’m getting an error (XD2455) before printing that I don’t understand where it says the ‘Print file command parameters are abnormal’.

Checking online, it suggests this error code is linked to the printer and either the wiper at the back or to some obstruction (dust and grime) on the X-axis bar upon which the head moves back and forth. So I checked both of those and lubricated the bar with a silicone spray and cleaned away a few filament crumbs, and then ran all three calibrations but, but when starting the same print again (also with another levelling check), it came up with the same error at the start of the printing.

I switched the printer off for 1 min and back on and then started a new print, with auto levelling, but again, after a short while into the levelling process itself this time, the error returned.

Having already done a separate set of calibrations, including levelling, independently of a print, I then tried to print without the calibration option selected, but the same error appeared.

After having done all the cleaning, I tried printing a different and simpler file of a few blocks and that went fine but when I immediately afterwards switched to printing the earlier, larger and more complicated model, the error appeared soon after the first filament was loaded.

So this error, despite what the internet and forums say, appears to be linked to the file rather than the printer itself and yet the slicer produced the G-Code file in the normal way, and I can’t think of anything that I should change to make the file more ‘acceptable’ to the printer.

Has anyone else had a similar experience?

Any ideas, or is Creality going to let me down again after problems with an earlier printer?

I believe this is the error I got when I import a file from another service (not Creality) and it creates a new printer that I don’t have. I don’t notice it until I get an error printing. Go back to slicer and check correct printer is chosen. I have also gotten this error when the wrong printer is chosen. Bed size is larger in the printer I sliced the file in the the printer I am trying to print on.

I agree it is probably the file. CFS could be causing problems with this code sometimes. One last thing. load the file into Creality Print again and check the printer that is chosen. If you get an error message when loading the file due to some parameter not being available, that that is the problem.

You could try slicing the file in another slicer, e.g., Cura.

Because it happens when print start to print, I personally, would blame a bad bed plate size parameter since that is what happened to me.

Thanks for your thoughts.

I am definitely using the right printer in the Creality Slicer (Creality K2 0.4 Nozzle) and the same with other models that print fine. I’m going to check the integrity of the G-Code in ‘gCode Viewer’ to see if anything comes up.

Thanks

The G-Code analyser has shown nothing unusual and I have again tried to print the same object and other parts of it and I get the same error. Yet items that printed last week print ok now. So must be something int he file bit I have no idea what.

Is there any software that can simulate or check if the print will work on the K2 before I actually try to print it?

I have now found out what the problem was due to endless trial and error - The G-Code file name had an apostrophe ‘s’ in it i.e. xxxxx’s.

All that for one character in the file name. You would think that Creality would have been more explicit in their error definitions and messages. Still not quite as finessed as one would hope!

1 Like

Thank you very much. I created a 3D model with AI of a spaceship for a game, and the name, being alien, was full of characters ('). I spent a lot of time trying to fix the STL file, thinking the AI ​​was doing it wrong. To add to the solution Julian mentioned, it turns out the location of the (‘) doesn’t matter; they just need to be in the original STL file. When I renamed the G-code to Orca, the error persisted, and it wasn’t fixed until I renamed the STL file and created a new G-code file from it. I suppose some trace of the STL name remains in the G-code file, which is why it happens even after renaming only the G-code.