Hello, it appears that I've found what appears to be a cause for a SFM not working, but I can't completely validate it. It seems to be the apparent cause for my use-case however. I'm opening this to make you aware of the information I've found out from my testing, so you're welcome to close this after reading since I don't feel like doing much more testing than I've done already.
When a battery storage is lower capacity than the destination output devices require per sub-tick, the entire disk halts all processes(not just the energy transfer).
The smallest network of devices I've seen this issue on includes 10 machines(3 crushers, 4 active reaction chambers, 3 unused reaction chambers),1 sink, 1 battery('generator' label, fed via Pipez pipes), and 7 drawers. When it fails to process the FE:: code, the item and fluid code beneath also halts.
Upon changing my code to have round robin by block on the FE:: output all processes begin properly again. This is likely because the storage can refill sufficiently when it's sending FE:: to my reaction chambers that a single 64-item cost mekanism operation can be performed by the entirety of the storage in the energy cube.
When attempting to test with 2 crushers and 2 drawers(and 128fe/t input into the energy cube), code that moves items between the 2 drawers and energy input/output continues to function, whilst my separate 19 device SFM network above pulling from the same cube fails entirely(pulling the other disk out to disable it so we're not fighting over FE between the two). I haven't tested by scaling up the setup since I don't particularly feel inclined to jumping into creative to test further.
However, testing by reducing the number of operations/tick that the mekanism devices are doing(reducing speed upgrades to 20), appears to also resolve the issue. When the mekanism crushers I'm using do 64/t(32 upgrades), the issue occurs once more. I don't know if testing would require scaling my number of devices far higher to introduce more FE consumption, but the problem appears to be related with the FE transfer to these high cost/tick mekanism machines. When they do more than one operation per tick, they eat the full cost rather than just 1/xth cost. So every time they crush one item, they eat the 64-item cost from my network until they hit 0, then halt SFM when they can't receive any more FE when SFM fails to transfer into them...
Good luck figuring out what's causing this though. Cheers! Love this mod.
Code below:
every tick do
input fe:: from generator front side
output fe:: to machine round robin by block top side
end
every 20 ticks do
input fluid::water from sink
output fluid::water to each reaction_chamber
--Crush
input from crusher bottom side
output certus_quartz_dust to drawer_dust
forget
if drawer_certus has > 192 certus_quartz_crystal then
input from drawer_certus
output 64 certus_quartz_crystal to crusher front side
forget
end
--Charge
input from chamber_charge
output charged_certus_quartz_crystal to drawer_charge
forget
if drawer_certus has > 128 certus_quartz_crystal then
input from drawer_certus
output retain 64 certus_quartz_crystal to chamber_charge
forget
end
--Duplicate
input from chamber_duplicate
output certus_quartz_crystal to drawer_certus
forget
input from drawer_dust
input from drawer_charge
output retain 32 charged_certus_quartz_crystal to chamber_duplicate
output retain 32 certus_quartz_dust to chamber_duplicate
forget
--Fluix Crush
input from crusher_fluix bottom side
output to drawer_fluixdust
forget
if drawer_fluix has > 128 fluix_crystal then
input from drawer_fluix
output retain 64 to crusher_fluix top side
forget
end
--Fluix Duplicate
input from chamber_fluix
output to drawer_fluix
forget
if drawer_certus has > 1024 certus_quartz_crystal and
drawer_charge has > 1024 charged_certus_quartz_crystal then
input from drawer_fluixdust
input from drawer_charge
output retain 32 fluix_dust to chamber_fluix
output retain 32 charged_certus_quartz_crystal to chamber_fluix
end
--Entro Crush
input from crusher_entro bottom side
output to drawer_entrodust
forget
if drawer_entro has > 128 entro_crystal then
input from drawer_entro
output retain 64 to crusher_entro top side
forget
end
--Entro Duplicate
input from chamber_entro
output to drawer_entro
forget
if drawer_fluix has > 1024 fluix_crystal then
input from drawer_entrodust
input from drawer_fluix
output retain 32 fluix_crystal to chamber_entro
output retain 32 entro_dust to chamber_entro
end
end
Hello, it appears that I've found what appears to be a cause for a SFM not working, but I can't completely validate it. It seems to be the apparent cause for my use-case however. I'm opening this to make you aware of the information I've found out from my testing, so you're welcome to close this after reading since I don't feel like doing much more testing than I've done already.
When a battery storage is lower capacity than the destination output devices require per sub-tick, the entire disk halts all processes(not just the energy transfer).
The smallest network of devices I've seen this issue on includes 10 machines(3 crushers, 4 active reaction chambers, 3 unused reaction chambers),1 sink, 1 battery('generator' label, fed via Pipez pipes), and 7 drawers. When it fails to process the FE:: code, the item and fluid code beneath also halts.
Upon changing my code to have round robin by block on the FE:: output all processes begin properly again. This is likely because the storage can refill sufficiently when it's sending FE:: to my reaction chambers that a single 64-item cost mekanism operation can be performed by the entirety of the storage in the energy cube.
When attempting to test with 2 crushers and 2 drawers(and 128fe/t input into the energy cube), code that moves items between the 2 drawers and energy input/output continues to function, whilst my separate 19 device SFM network above pulling from the same cube fails entirely(pulling the other disk out to disable it so we're not fighting over FE between the two). I haven't tested by scaling up the setup since I don't particularly feel inclined to jumping into creative to test further.
However, testing by reducing the number of operations/tick that the mekanism devices are doing(reducing speed upgrades to 20), appears to also resolve the issue. When the mekanism crushers I'm using do 64/t(32 upgrades), the issue occurs once more. I don't know if testing would require scaling my number of devices far higher to introduce more FE consumption, but the problem appears to be related with the FE transfer to these high cost/tick mekanism machines. When they do more than one operation per tick, they eat the full cost rather than just 1/xth cost. So every time they crush one item, they eat the 64-item cost from my network until they hit 0, then halt SFM when they can't receive any more FE when SFM fails to transfer into them...
Good luck figuring out what's causing this though. Cheers! Love this mod.
Code below:
every tick do
input fe:: from generator front side
output fe:: to machine round robin by block top side
end
every 20 ticks do
input fluid::water from sink
output fluid::water to each reaction_chamber
--Crush
input from crusher bottom side
output certus_quartz_dust to drawer_dust
forget
if drawer_certus has > 192 certus_quartz_crystal then
input from drawer_certus
output 64 certus_quartz_crystal to crusher front side
forget
end
--Charge
input from chamber_charge
output charged_certus_quartz_crystal to drawer_charge
forget
if drawer_certus has > 128 certus_quartz_crystal then
input from drawer_certus
output retain 64 certus_quartz_crystal to chamber_charge
forget
end
--Duplicate
input from chamber_duplicate
output certus_quartz_crystal to drawer_certus
forget
input from drawer_dust
input from drawer_charge
output retain 32 charged_certus_quartz_crystal to chamber_duplicate
output retain 32 certus_quartz_dust to chamber_duplicate
forget
--Fluix Crush
input from crusher_fluix bottom side
output to drawer_fluixdust
forget
if drawer_fluix has > 128 fluix_crystal then
input from drawer_fluix
output retain 64 to crusher_fluix top side
forget
end
--Fluix Duplicate
input from chamber_fluix
output to drawer_fluix
forget
if drawer_certus has > 1024 certus_quartz_crystal and
drawer_charge has > 1024 charged_certus_quartz_crystal then
input from drawer_fluixdust
input from drawer_charge
output retain 32 fluix_dust to chamber_fluix
output retain 32 charged_certus_quartz_crystal to chamber_fluix
end
--Entro Crush
input from crusher_entro bottom side
output to drawer_entrodust
forget
if drawer_entro has > 128 entro_crystal then
input from drawer_entro
output retain 64 to crusher_entro top side
forget
end
--Entro Duplicate
input from chamber_entro
output to drawer_entro
forget
if drawer_fluix has > 1024 fluix_crystal then
input from drawer_entrodust
input from drawer_fluix
output retain 32 fluix_crystal to chamber_entro
output retain 32 entro_dust to chamber_entro
end
end