Вопрос по SCADA iFIX

[KruGGoK]

Здравствуйте.
Существует такая проблема. У нас используется SCADA iFIX для автоматического налива мазута на эстакаде. Ситуация такая,iFIX формирует данные о каждой налитой вагоноцистерны в .txt файл. Это происходит путем нажатия оператором кнопки "Конец налива" на АРМЕ. Иногда происходит не правильное формирование данных.
Рассмотрим пример:
1 бочка налито 62 тонны в .txt записано 62 тонны
2 бочка налито 60 тонн в .txt записано 60 тонн
3 бочка налито 61 тонна в .txt записано 62 тонны
4 бочка налито 58 тонн в .txt записано 58 тонн
5 бочка налито 60 тонн в .txt записано 62 тонны

В среднем наливается 65 бочек одновременно по обоим путям. Из примера видно, что данные попадают в .txt файл из предыдущей бочки через одну. Но это происходит не всегда. В большинстве наливах всё пишется верно, но иногда происходит вот такая фигня. Причём данные могут быть записаны как и в большую сторону так и в меньшую.
У кого какие мысли, где капать???

[Ryzhij]

Отчёт формируется как, не через базу данных ли?
Привязка вагонов-цистерн (бочек) в базе, часом, не по номерам самих вагонов идёт?
Если вагон с тем же, уже имеющимся номером в базе, номером через месяц-другой снова под налив придёт, как система отреагирует?
У нас-таки была "залепа" в этом...

[DelSnos]

Отчёт формируется как, не через базу данных ли?

Похоже, что напрямую скриптами по нажатию кнопки. У Ifix вроде своя (?) база данных реального времени и есть ли возможность писать оттуда в файл?

[Ryzhij]

Потому и спрашиваю - нагородить генераторов отчётов вокруг любой базы можно.
Какими угодно средствами.
И вызывать их потом по скрипту.
У нас вон австрийские разработчики на Дельфи и dBase изголялись.
Но суть не в этом, в типовых задачах людям свойственно делать типовые ошибки. Тут, похоже, или два программных модуля индексы для выборки считают по разному. Один, например с нуля, а другой с единицы.
Или со старыми записями по номерам вагонов идёт перехлёст.

[hell_boy]

Без исходника скрипта не разберешься. У iFix есть несколько видов истории: Historian, Advanced Historian, iHistorian. В любом случае: прямого доступа к истории не будет, только через API, OLE DB, ODBC. В последнем случае - очень большие ошибки округления. Еще бывают ошибки, связанные с локалью: на экране дробная часть числа отделяется от целой с точкой, в скрипте - запятой, в ODBC - запятая воспринимается как разделитель между столбцами. Еще, может быть, дело в скорости нажатия оператором кнопки "Конец налива". Введена она не просто так, после окончания работы насоса еще какое-то время расходчик будет показывать самотек пены, если вовремя эти показания не отсечь, то всегда будут завышенные итоговые данные. Кстати, у Вас так и округляется до тонн? Хорошо живете ;)

[Бондарев Михаил]

Хорошо живете ;)

тонна мазута - это всегда тонна мазута. В хозяйстве не помешает, да и для бюджета полезно семейного.

[SaNNy]

Здравствуйте.
Существует такая проблема. У нас используется SCADA iFIX для автоматического налива мазута на эстакаде. Ситуация такая,iFIX формирует данные о каждой налитой вагоноцистерны в .txt файл. Это происходит путем нажатия оператором кнопки "Конец налива" на АРМЕ. Иногда происходит не правильное формирование данных.
Рассмотрим пример:
1 бочка налито 62 тонны в .txt записано 62 тонны
2 бочка налито 60 тонн в .txt записано 60 тонн
3 бочка налито 61 тонна в .txt записано 62 тонны
4 бочка налито 58 тонн в .txt записано 58 тонн
5 бочка налито 60 тонн в .txt записано 62 тонны

В среднем наливается 65 бочек одновременно по обоим путям. Из примера видно, что данные попадают в .txt файл из предыдущей бочки через одну. Но это происходит не всегда. В большинстве наливах всё пишется верно, но иногда происходит вот такая фигня. Причём данные могут быть записаны как и в большую сторону так и в меньшую.
У кого какие мысли, где капать???

Скорее всего ошибка кроется в алгоритме, который реализован скриптом (VBA) и так просто сходу ее не исправить. Лучше всего обратиться с этим вопросом к разработчикам системы автоматизации

[KruGGoK]

Здравствуйте.
Существует такая проблема. У нас используется SCADA iFIX для автоматического налива мазута на эстакаде. Ситуация такая,iFIX формирует данные о каждой налитой вагоноцистерны в .txt файл. Это происходит путем нажатия оператором кнопки "Конец налива" на АРМЕ. Иногда происходит не правильное формирование данных.
Рассмотрим пример:
1 бочка налито 62 тонны в .txt записано 62 тонны
2 бочка налито 60 тонн в .txt записано 60 тонн
3 бочка налито 61 тонна в .txt записано 62 тонны
4 бочка налито 58 тонн в .txt записано 58 тонн
5 бочка налито 60 тонн в .txt записано 62 тонны

В среднем наливается 65 бочек одновременно по обоим путям. Из примера видно, что данные попадают в .txt файл из предыдущей бочки через одну. Но это происходит не всегда. В большинстве наливах всё пишется верно, но иногда происходит вот такая фигня. Причём данные могут быть записаны как и в большую сторону так и в меньшую.
У кого какие мысли, где капать???

Скорее всего ошибка кроется в алгоритме, который реализован скриптом (VBA) и так просто сходу ее не исправить. Лучше всего обратиться с этим вопросом к разработчикам системы автоматизации

А своими силами можно реализовать? Я тоже думаю дело в скрипте. По поводу кнопки "Конец налива" пробывал и сразу её нажимать и наоборот с задержкой, ошибок не возникало. По поводу округления тонн, это я пример привёл, естественно там все до десятых, пример 62380 и т.д. и реализовано с VBA. Может мне какие данные сюда отправить, например скрипт?

[SaNNy]

Да, выложите скрипт, возможно это поможет решить проблему