What are the energy losses from transformers?

    I wanted to confirm some behavior I observed in game as being officially desired result.


    Most machines have an internal buffer, though it's precise size is not documented (outside of the source code anyway) I suspect it is at least 128 and probably 512.


    If I have an MFS unit, lossless lengths of cable, TFs and a machine, will the machine only draw a pulse of power when it can handle the full 512eU output of the MFS unit? (16 pulses of 32 in one tick)


    :MFS-Unit: :Glass Fibre: :Glass Fibre: (MVTF)(gold 2x ins) :LV-Transformer: :Cable: :Macerator:

    The machine "buffer" or storage is pretty well documented in the wiki for most machines. Usually it's equal to the cost of 1 operation. Induction furnaces are a bit different though. But for a Macerator, one operation costs 625 EU and it has 625 EU storage. So when one operation completes it would dump the storage to the progress bar then "call for" 625 EU. (which is slightly more then 512) [some machines work like that, others gradually use the power, constantly filling the progress bar.]


    But yes, it's been documented that transformers send multiple packets of LV or MV when sending. [So it's technically possible to get 512 EU/t out of a 32 EU/t LV transformer (I'm pretty sure)]


    Alblaka also mentioned that the EU senders check for "needed power" and send "need + loss energy" so in your example the MFSU probably sends 1 packet of 512 [which gets converted to 16 packets of 32] then it'd send 113 EU which would be converted to 3 packets of 32 and 1 packet of 17 [or 4 packets of 28.25]; assuming your machine needed 625 EU.

    I ran my own experiment with an MFS, MVTF, LVTF, 1x glass 'wire', 2x gold wire (was out of copper wire at that moment).


    The first run I got odd values, so I retested with a full stack of 64 cobblestone.



    100312 - 99096 = 1216
    1216/2 = 608
    625*64 = 40000
    98488 - 60088 = 38400
    (98488 - 60088) / 64 = 600


    Ignoring the initial charge (which apparently cost exactly 608 for wrench and replace), I observed a sporadic draw of 32eU/pulse that vaguely matches the 2eU/tick specification of the unit.


    Strangely I also see that an operation costs 600 and not 625 as predicted.

    Ran a similar test with just a batbox + macerator (and a set amount of EU). Same results:
    Placing macerator consumed 608 EU, cycle of 64 items consumed 38400 EU (600 EU / process).
    And the batbox definitely was only sending packets of 32 EU, but I wouldn't call them sporadic.
    Watched it for a minute, it sent 75 packets. 75/60 = 1.25 / sec x 32 EU = 40 EU/s
    Alblaka has already said that there's 20 ticks per second so... 40/20 = 2 EU/t (as advertised) :)


    *runs a couple tests at the end* mixed results, but average EU / process was 600.... 2@608 and 2@592


    [Makes me wonder how the whole "need + loss" thing works, or if it always sends packet size and then just
    subtracts the loss from storage. And it seems like machines don't "call for" energy unless they can receive
    a full packet size. (maybe that's why the 32 EU ticks seemed sporadic for you cos it would have sent 4
    quickly then waited a second or two before sending another set of 4, since you were using a MFE) *shrugs* ]

    I ran a test with 41 glass instead of 1 and the same stack of 64 cobble. The result:


    Packets of 32 were sent from the MFS unit over the glass; loss was one unit per packet; 1200 packets later the operation was complete.


    Conclusions: The Wiki and current documentation are wrong/misleading on various points.

    Quote from MJEvans

    I ran a test with 41 glass instead of 1 and the same stack of 64 cobble. The result:


    Packets of 32 were sent from the MFS unit over the glass; loss was one unit per packet; 1200 packets later the operation was complete.


    Conclusions: The Wiki and current documentation are wrong/misleading on various points.

    Curious... what was the total energy used to macerate the 64 cobble? 39600? (cos it seems like it should be 2 loss per 128 packet not 1 per 32 packet... maybe it's having a problem with fractions/decimals) [which would be 39000 EU for the same 64 cobble] either way both those numbers are still cheaper then the advertised 625 EU / operation.

    All experiments run with 64 cobble
    600*64 = 38400


    Lossful
    Experiment 2.A: MFS, 41 glass wire, MVTF, gold wire (2x ins), LVTF, copper wire (ins), Macerator
    101573 - 61973 = 39600
    600*64 / 32 = 1200.000
    600*64 + 1200 = 39600
    101573 - 61973 = 39600



    Lossless
    Experiment 2.B: MFS, 39 glass wire, MVTF, gold wire (2x ins), LVTF, copper wire (ins), Macerator
    61973 - 23573 = 38400


    Additionally I observed the specific difference of 33 per update and 32 per update respectively. The MFS dequeued packets of 33eU.


    This would actually be a more simple model if all TFs had a buffer (inductive capacity) of their high side and would only transfer if it were empty/full if stepping down/up respectively.


    Additionally I noticed that the measuring tool when used on a TF counts both incoming and outgoing packets (divide measurements on TFs by 2 to get the correct value)

    Quote

    This would actually be a more simple model if all TFs had a buffer (inductive capacity) of their high side and would only transfer if it were empty/full if stepping down/up respectively


    I'm pretty sure they do, but that it doesn't matter (I could be wrong though). I just know I've blown up a couple items when the only possible explanation was the TF (LVT) was holding a packet of MV and sent it to a device. [Well I guess another explanation could be that a packet was both sent and received from/to the exploding device during the same tick... ]

    Actually better would be double-buffering (2x the highest side as buffer size; same 'only push/pull' full high-side packets; the low side would still give whatever was asked up to it's limit) since that could potentially simplify a lot of code if these were 1 tick delay small buffers.


    As for your issue; was that possibly related to the SMP 'paint doesn't separate wires' issue? Or maybe 'face direction not preserved' issue (I hear they are the same root cause)?