Thank you
Though one question to that: For this block update the extractor needs active power?
I tried the comparator-setup not connected to the engine control, so that the extractor kept being powered. Then it works totally fine. Nothing to do -> redstone signal on, put in an ore -> redstone signal stopped. When there is no power - cause the comparator shut it down - it seems to not work.
(sorry if this is a stupid question, but while I understand stuff like block-updates on the surface, the deeper technical details for these things are a book with seven seals for me)
If you haven't worked out the problem yet, could you maybe provide us with a screenshot of your set up? I can see no reason why you'd need or want to detect any block updates for this or any other machine. I can only think of a handful of places where that's even useful, most of which involve making old school redstone circuits.
I have an idea about what might be going on here, though. On the surface of it, it sounds like you're trying to take the comparator's analogue redstone signal (RSS) output and plug it in directly to your engine control unit (ECU), which is effectively a binary (or digital, if you like) device, being a strictly on/off switch for our purposes here. Of course, this "works" logically, but it's obviously not giving you the results you're expecting. The problem being that the ECU doesn't care about the data being transmitted by the comparator. That is, the "has work" information that the comparator is taking as a reading from the extractor is lost at a logical on/off gate, the ECU.
Remember that the comparator attached to an inventory outputs a positive RSS strength (RSS = 1 ≤ X ≤ 15) when it detects that the inventory contains a given volume (RSS = X, where X is not equal to zero) and outputs no RSS when the inventory is empty. Thus, whether your comparator's output is 1 (the attached inventory almost empty) or 15 (full), they both represent a "true" or "on" state insofar as the ECU, which only accepts discrete binary signals, is concerned. Critically, the ECU turns itself
off when it is provided with a
positive RSS (of any strength, all effectively RSS "on" signals).
Thus, the simplest solution is to supply an inverted RSS (a simple NOT logic gate) to the ECU and your engines should run continuously while there are items in your extractor's inventory and shut down again when there aren't.
However, in my view at least, this is not very interesting. Yes, it gets the job done. But, remember that comparators output an RSS strength equal to the proportion of an inventory's current volume over its maximum capacity, measured in one fifteenths increments. If you can figure out a way to use that information such that it governs the up and down time of your engines when fixed quantities are reached rather than being merely on or off regardless of volume, larger or small, you can avoid problems where your engines start up and shut down over short intervals (eg: if the input chain in your supply of ore to a grinder or extractor is slower than their output, any case where one or the other is out of sync). To get you started, if you're interested, investigate Minefactory Reloaded's Programmable RedNet Controller block, paying particular attention to the SR-Latch circuit.
I would also caution you against taking your comparator readings off of the internal inventory of the extractor itself, which is comparatively small. Using a larger chest as an input buffer that feeds into the extractor will extend the time that your extractor "has work", ensuring that the duty cycle of your engines lasts longer, thus giving you better fuel economy (less time and energy spent getting the engines up to speed and losing it again when they are shutting down/stopping). More importantly, however, it will help avoid spilling items on the ground. Since it can take a few moments for some engines to wind down to a stop, they're still "doing work" up to a point, even as their RPMs slow, which if their output chests are full can make a (potentially laggy) mess if you're not careful, especially with machines tuned for 1-tick operating speeds. Personally, I use two chests, one to take readings from, the second to feed into the first and serve as an overflow buffer, just in case