Multiple IFSes - best approach to adding support to zMod?

[ninjamida]

So, I've mentioned a couple of times that I'm working on a project to support multiple IFSes. (In case "IFSes" does not translate properly, it is just meant to be a plural of "IFS".)

The setup I'm making relies on a "splitter" device that sits inbetween the printer and the IFSes. My intent is to simply have zMod treat it as a large IFS - so for example, suppose we have two IFSes and want to switch to color 3 on the second IFS; zMod would send a command like "F24 C7", and my device would receive this, and send "F18" to the first IFS and "F24 C3" to the second IFS. It would then pass the second IFS's response back to the printer (or an error message if the first IFS F18 fails).

I have already made very good progress on this. It's not ready to start integrating into zMod yet, but it's at the point where I can connect two IFSes to it, and send commands from my PC to simulate printer input. There are some edge cases to deal with (eg: the F24 example above, it doesn't yet make the other IFSes run F18, I thought of that while testing but didn't implement it yet) and I haven't implemented F13 (which will need special handling) yet, but it's coming along very nicely - I think I'll be doing my first 5+ color print within a few days to be honest, unless I run into problems with how to attach an 8-in-1 connector. (I have one, I just have to figure out how I'm attaching it.)

Therefore, only a few changes are needed in zMod. However, this would require changes to the Python scripts - I haven't looked too closely at plugins, but I believe they can only add entirely new python scripts, not alter existing ones?

At this stage, I believe the only change that would be needed in zMod is to remove the hardcoded four color limit, in favor of either a "not likely to be exceeded in practice" limit like 32, or setting the limit dynamically based on how many colors the IFS reports support for. Perhaps we could introduce a new command the stock IFS doesn't recognize for this purpose, say, send "Z1" and the splitter will respond telling how many IFSes it can support (and then we just times that by 4 to get the number of colors). If it's a stock IFS, it won't recognize the command and won't send any response, and we know it's just four colors available. We can differentiate this from "no IFS attached" by trying a stock command like F13.

For reference, my splitter unit is based on an RP2040 Zero (using MicroPython so should work without modification on an RPi Pico too, and should be fairly easy to port to other similar boards). I'm personally making my unit for just two IFSes, but I'm designing and coding it in such a way that you can add as many IFSes as you have spare GPIO pins for (one additional pin is needed for each additional IFS - a Facebook user suggested an idea for a hack to run all the IFSes off a single UART TX/RX pair, and with a bit of tweaking, I managed to get their idea to work). On an RP2040 Zero, that would mean someone could theoretically attach 15 IFSes; and on larger boards, even more. I don't think anyone actually will attach that many though - I think it would be perfectly fine to work with an upper limit of four or eight IFSes for now, and increase that limit in the future if anyone actually needs it.

What I'm wondering is, what do you think is the best approach for this? I can think of a few ideas:

• If there is a way to modify the py scripts in a plugin, that would be best.
• Since the actual changes needed are quite minor, they could potentially just be integrated into the mod.
• Maybe you'd rather keep this out of zMod, and it would be better for me to make a fork with support for the splitter.
• Or a hybrid approach - modify ZMod to remove the four color limitation, and instead set the limit dynamically via a variable. ZMod itself never changes this variable from its default value, but plugins can change it. Then, I make a plugin for my splitter, that makes use of this feature.

I think the last option may be worth giving some thought to if its practical, because other people might also want to design their own modifications in this regard that are different from mine, eg. they may wish to replace the IFS with an ERCF or other open-source MMU.

[ghzserg]

modify ZMod to remove the four color limitation, and instead set the limit dynamically via a variable. ZMod itself never changes this variable from its default value, but plugins can change it. Then, I make a plugin for my splitter, that makes use of this feature.

Add a command that will set the number of available colors. This will essentially change a variable that other commands will read.

[ninjamida]

Just a status update: I'm finally at the point where it's time to start seriously looking at the zMod integration.

I've built my splitter box, and it can hold a stable connection to the printer. I left it on overnight last night (unmodified zMod at this stage, maybe a version or two behind current), not doing anything active but just to make sure that the regular F13 commands are all being received and responded to correctly and that zMod does not at any point think the "IFS" is disconnected. It worked! The only active command I've tested so far is sending an F18 from zMod; my splitter correctly receives it and sends F18 to both IFSes.

I have done more in-depth testing without the printer (but with the IFSes) and it does indeed seem to be redirecting commands correctly, and automatically adjusting the channel. So as far as zMod needs to know - it's just talking to an IFS with eight channels instead of four. Everything else is handled by my device itself.

Regarding the changes to zMod - while not tested yet, I've written code that should replace the hardcoded limit with one the user (or plugins) can alter via SAVE_VARIABLE. I'm going to start testing that today, since all seems well with the splitter device now (or at least well enough to start testing the zMod integration).

[ninjamida]

Well, very exciting - I just did my first print through the splitter! It wasn't an 8-color print - it was only four colors, because I didn't want to add the variable of the 8-in-1 into this early test. But those four colors, were channels 5, 6, 7 and 8. :)

I think I will skip the "channels 1, 2, 5 and 6" or whatever test and go straight to 8 colors for the next test. I don't think any issue caused by the 8-in-1 will arise that I won't be able to distinguish as an 8-in-1 issue rather than a splitter issue.

Yes, that also means the zMod integration is... well, not sure if it's complete, but to the point it's useable. 80% of this was literally just replacing hardcoded limits of 4 with adjustable ones. Now... I'm correct in thinking "Adventurer5M.json" is also used by the native screen, right? Because of that assumption, I've avoided modifying it (though maybe that's not a problem as long as I'm only adding extra data, not removing anything?), and instead saving the color data for extra channels to a seperate file.

[ninjamida]

Regarding the plugin: Because it involves Python scripts rather than just CFG files, it needs to reboot the printer after installing / uninstalling / update. I can easily achieve this in the install.sh / uninstall.sh scripts, but it seems update.sh is a hardcoded special case for g28_tenz and isn't run when updating other plugins.

I do notice that when Z-Mod is updated via the update manager it reboots, so obviously there's some way to mark updates as requiring reboot, but I can't figure out how. (Obviously, a difference here is that the reboot is only necessary if the plugin is actually enabled.)