Same here.
Unfortunately its unusable for the MK4S.
Ive tested the same procedure as you @THZK100SC

Any suggestions how to deal with it?
We need Orca ;)

I don't know the exact function of the notes in the printer settings. Personally, I thought that if I entered 'PRINTER_MODEL_MK4S' in the printer notes, the change would be reflected in the overall G-Code, where the correct printer name would be set.

Unfortunately, it doesn't work that way!

As soon as I have time, I will test how PrusaSlicer works.

The temporary solution is to change the printer start G-code to:

Unfortunately, this will disable the automatic check. :-(

Same here
Can't make it work properly
I tried switching from PrusaSlicer but it's impossible without a matching profile

I am having the same issue I would Ideally love to have all the print profiles moved from PrusaSlicer to Orcaslicer for the MK4S but things are not working 100% properly. I am also noticing that I cannot add any of the same system filaments to my prusa profile just my bambu and vyper profile

G-Code loaded without warnings and printed after I've changed all instances of MK4 and MK4IS to MK4S in the G-Code via text editor. Maybe this might help.

Also I'm wondering why in printer setup of Orca Slicer the MK4S is named MK4IS. Never read about an MK4IS before. Maybe it derives from all Prusa bedslingers belonging to the I3 series. But it is not the correct name for the MK4S.

G-Code loaded without warnings and printed after I've changed all instances of MK4 and MK4IS to MK4S in the G-Code via text editor. Maybe this might help.

Also I'm wondering why in printer setup of Orca Slicer the MK4S is named MK4IS. Never read about an MK4IS before. Maybe it derives from all Prusa bedslingers belonging to the I3 series. But it is not the correct name for the MK4S.

You are mistaken, MK4IS is the input shaper profile of the regular MK4 printer, not MK4S.
You're basically running MK4S with regular MK4 input shaper settings. This is not a proper MK4S profile.
It works but you don't take advantage of the MK4S capabilities.

Thanks, for the clarification. For regular prints with my MK4S I'll stick with Prusaslicer for now. With my other printers I use mainly Orca. I only gave Orca a try with the MK4S this time because I wanted to take advantage of the built-in calibration features of Orca.

Thanks, for the clarification. For regular prints with my MK4S I'll stick with Prusaslicer for now. With my other printers I use mainly Orca. I only gave Orca a try with the MK4S this time because I wanted to take advantage of the built-in calibration features of Orca.

Have you found any benefit in calibrating the MK4/S using Orca? From your experience, is it worth pursuing, or is the default profile in PrusaSlicer sufficient?

The flow test is awesome. Something you cant do with PS...

Any news?

I don't have any news at all.

I mostly finished with profiles yesterday, I just need to go through and check retraction settings match PrusaSlicer profiles before sending a PR.

I've set them up based on the "Standard" profile that the MK4 profiles use in OrcaSlicer, but was wondering whether it'd be better to match PrusaSlicer's speed/quality/fine detail/draft setup. Any opinions?

It would be fantastic if the Orca settings meet the Prusa ones. But we all know, that the settings are updated by prusa sometimes so it would be a (good) snapshot anyway. Prusa settings just works.
Thank you! We all appreciate it - especially for calibration 

I agree with @Racemade
Prusa has already tweaked the settings for the MK4S very well in PrusaSlicer, why start with standard ones in Orca and tweaking it again to match what’s already there in PrusaSlicer?
IMO you better use PrusaSlicer when printing multicolor using the MMU. So it would be easier to have the same settings in Orca for single color prints.
I don‘t expect to see a lot more changes for the MK4S settings in PrusaSlicer. I think the MK4S is the last i3 model in Prusa's lineup and development is concentrated on the CoreXY printers.

A quick update ... I've reworked all the machine, process, and filament profiles using https://github.com/theophile/SuperSlicer_to_Orca_scripts. Unfortunately the generated configs all still require a lot of work after the initial generation, mostly since the profiles in PrusaSlicer make extensive use of multiple inheritance, which I don't think OrcaSlicer supports. The generated files are also not always correct -- for example, missing fields that OrcaSlicer requires.

Fixing these up has been tedious, as OrcaSlicer's behaviour seems pretty arbitrary when it encounters broken config files. Sometimes filament profiles don't appear in the config wizard, sometimes once added the machine profiles just don't appear in the dropdowns after adding. I haven't been able to get any logs out of OrcaSlicer which help me track down errors the configs easily, and haven't found any reasonable documentation of which fields are required, and which types they should be, so there's been a fair amount of trial and error and the process of restarting OrcaSlicer to try each change is tedious.

I've just found that OrcaSlicer conflates printer variants and nozzle diameters in a couple places in the code causing some of the hard to debug behaviour described above. This means that HF variants need to be moved to a separate printer model, as far as I can tell. I'm currently working on getting those split out... hoping to be done with this within a couple of days.

If anyone wants to start testing and/or looking over what I've got, it's at https://github.com/rcloran/OrcaSlicer/tree/prusa-mk4s-auto . I'll be putting together the PR soon, as soon as I've run through a couple more test prints etc. It uses https://github.com/rcloran/SuperSlicer_to_Orca_scripts (which adds a bunch of Python scripts to the tool it was forked from) to automate the process, so updates should be relatively easy in the future, but the tool isn't flexible enough to handle importing other printer profiles.

I've run into a difference between Prusa and Orca behavior that means behaviour is different for the same settings, and wondering if anyone has any preferences on how to resolve it.

The profiles set "retract on layer change", and a minimum travel after retraction of 1.5mm. In Prusa Slicer, this means that layer changes on an aligned seam do not retract (as if the minimum travel requirement takes precedence). In Orca Slicer, we have retractions on aligned seams. The impact of this is that PS's seams are a little over-extruded, while OS's are under extruded.

Tests below using 0.20mm SPEED @MK4S 0.4 profile with infill set to 0% (and it wasn't at all speedy because of minimum layer time).

Prusa Slicer default settings:

Orca Slicer directly translated settings:

Prusa Slicer changed to a 0.00001mm minimum travel distance to force a retraction:

Orca changed to not retract on layer change:

I had a bit of a hard time photographing the altered PS print, it definitely under extrudes, but maybe a bit less than the default OS settings.

I've noticed this discrepancy have an impact on "real" prints like the Autodesk FDM test, where the seam placed on the inside corner leading up to the top platform looked like a pretty noticeable gap when printed from OS.

When slicing two of these test cylinders (or, presumably any object(s) with multiple perimeter loops per layer), both perform a retraction on layer change anyways due to the travel, but both seems look more like the over-extruded case. IMHO the configuration most similar to the actual behaviour of the Prusa profiles would be to disable retraction on layer change in Orca.

You've figured out a great thing. Overall, OrcaSlicer is worse than PrusaSlicer if you print on MK4 (S) for example. I have also noticed this behaviour. I also noticed a problem with the G-Code.

Anyway, we still don't have a solution to add new printers to OrcaSlicer. I'm having trouble generally adding a new printer. I keep having to create a new printer from a preconfigured one. And this solution is stupid. Personally, I think that the compatibility of OrcaSlicer with Prusa is not very good.

EDIT: I renamed the thread title. I noticed that there is a pull request ... #8279

However, this pull request still does not solve the overall problem of adding new printers.