Хорошая новость про случаи, когда связи перепрыгивали с одного блока на другой.
Мы таки смогли это смоделировать и, как оказалось, это проблема не лоджика, а прекрасной операционной системы Windows, начиная с версии Win7 и лишь на некоторых
пиратских сборках этой системы.
Баг возникал в процессе
сохранения проекта. При сохранении SMArt готовит свою часть проекта, связанную с экранами, а SMLogix берёт эту часть и присоединяет к основной части, содержащей FBD.
Выглядит это так: SMArt сохраняет свою часть в файл в папку %temp% и затем передаёт сигнал в SMLogix "я таки всё сделал - работай дальше". Лоджик, получая сигнал от СМАрта, берёт этот файл и приписывает к основному файлу проекта.
Проблему подкинул драйвер файловой системы Windows. Как-то так получается, что если сохранить файл и затем быстро его открыть, то часть информации, которая пока находится в дисковых буферах и не скинута на диск, оказывается недоступной или устаревшей, если файл сохранялся поверх старого.
Эта ситуация называется
некогерентностью буфера и за ней должен следить именно драйвер файловой системы или драйвер устройства хранения.
Как бы то не было, при сохранении проекта часть проекта оказывалась устаревшей и выражалось это в перепрыгивании некоторых связей с места на место.
Такая ситуация не очень распространена и в основном случается на компьютерах с медленным жёстким диском (или когда одновременно с диском работают несколько программ или когда процессор слабый очень), да и то не всегда. На быстрых компьютерах с SSD её получить невозможно.
В SMLogix версии 3.27 данную ситуацию искоренили напрочь путём введения проверки структуры связей при сохранении и открывании проекта.
В SMLogix версии 3.26 внедрили задержку и принудительную очистку дисковых буферов перед соединением частей СМАрт и FBD. Это несколько замедлило сохранение и довело ситуацию до того, что мы не смогли повторить проблему, как ни старались.