Material Settings Glitch

snowgoer540 wrote: Any chance you could attach the materials file too? I could give your experiment a go on my machine, see what happens.

Here ya go.

It may not be a valid test. How big is your material file in bytes.?
what sector size does fdisk /l report?

The sector size in Linux is 4096 or 8192 bytes. So on a file read a complete sector is retrieved from the HDD and held in an internal buffer. (We do buffered IO with PC's right?) So unless the entries are more than a sector apart its not really valid. Also seek times come into play so if the sectors are sequential, the read times will be faster than if they are random and a few sectors apart. BUt SSD's might come into play here.

Very early in the piece, I had my M66 waiting for one second and that was not enough so I changed it to 2 seconds. Provided you load valid tools, this will not hold up performance because they will be found quicker than the max time allowed..

EDIT: This is definitely NOT a valid test. That file is only 38 k long so after the initial read, it is all buffered. Even back in the good old floppy days, with 512 byte sectors, the data is less than 1 sector long...

The materials are read into a dict, so are held in memory.

Has that always been the case? I just wonder why I had problems in the first place.

Yep, since the materials were first included.

It is possible that I changed the handshaking, not 100% sure.

phillc54 wrote: Yep, since the materials were first included.

Strange. its a very small data structure compared with some of the file processing I've done with Python recently. I'll have to check my file size when I'm near my machine again. I don't understand why it took more than 1 sec back then.

phillc54 wrote: It is possible that I changed the handshaking, not 100% sure.

Ahh.

But the dict should be indexed internally surely?

Yes, but the M66 needs to wait for the digital pin toggle which is done by the handler.