[haker_fox 60]

22 minutes ago, jcxz said:

Как зачем? А когда ещё крановщику сгонять попить пивка если не в то время, пока винда или линух грузятся? Или пока оне ставит дрова под следующий вид груза?

Ох уж ваши эти шуточки Люто плюсую))))

[AlexandrY 2]

54 minutes ago, haker_fox said:

Если то же самое я могу сделать на базе stm, lpc? 

Вы сможете меня убедить в этом только перечислив свои бюджет, инструментальные средства, набор софта и указав продолжительность разработки.
Сами по себе  STM и LPC ни о чем не говорят и ничего не решают.
Просто мы ж в контексте и я примерно представляю с чем вы будете разрабатывать на этих LPC. 
Я же всегда подразумеваю варианты с минимальным бюджетом времени и средств при одинаковом уровне качества.

Да, и кран это не "прибор" на столе, тут просто надо проникнутся как вы в лютый мороз лезете по крану чтобы перепрошить какой-то LPC.
Отобьет сразу  охоту делать самопалы, и руки сами потянутся к PLC с IOT-ами.  

[haker_fox 60]

3 minutes ago, AlexandrY said:

Отобьет сразу  охоту делать самопалы, и руки сами потянутся к PLC с IOT-ами.  

Самое правильно, ИМХО, для крана и прочей подобной кухни использовать ПЛК. Но мы всё-таки о самодельном. Но и в этом случае можно исключить прошивание МК в мороз. Можно предусмотреть проводной или беспроводной интерфейс.

4 minutes ago, AlexandrY said:

Я же всегда подразумеваю варианты с минимальным бюджетом времени и средств при одинаковом уровне качества.

Ну в вашем случае, я знаю, у вас есть фреймворк. Вам только нужно писать целовое ПО. А использование stateflow, как я понимаю, резко вам экономит время....

[AlexandrY 2]

50 minutes ago, haker_fox said:

Самое правильно, ИМХО, для крана и прочей подобной кухни использовать ПЛК. Но мы всё-таки о самодельном. Но и в этом случае можно исключить прошивание МК в мороз. Можно предусмотреть проводной или беспроводной интерфейс.

Проблема часто в том что ПЛК не так удобны как иногда кажется.
Во-первых как ни странно у них не весь ассортимент заявленный в каталогах есть в жизни. 
Во-вторых траблы и аномалии в ПЛК (а они там бываю) решаются очень медленно.
В-третьих среды разработки для ПЛК годны только для отладки примитивных алгоритмов. 
Ну и там дальше идут габариты этих ПЛК, кусачая цена, ненормированное потребление, и тот же зачаточный IoT не идущий ни  в какое сравнение по сравнению с тем что можно сделать самому. 
Интерфейс оно конечно да, но куда? В чисто поле? 
Не, что ни говорите, а IoT это спасение для разработчиков.  И пограничные вычисления тож. Одно только наличие под рукой матлабовской технологии   run software-in-the-loop (SIL) and processor-in-the-loop (PIL) сильно упрощает жизнь при настройке алгоритмов управления сложной кинематикой. 
 

[haker_fox 60]

1 minute ago, AlexandrY said:

В-третьих среды разработки для ПЛК годны только для отладки примитивных алгоритмов. 

Ну, а крану много-ли надо? Но даже если абстрагивароваться от крана, ПЛК же где только не стоят. Наверно не всё там так уж и примитивно.

2 minutes ago, AlexandrY said:

Интерфейс оно конечно да, но куда? В чисто поле? 

Ну в виде розетки у фундамента крана. Либо точка доступа. Всё-равно отладка и настройка возможно только рядом с объектом.

3 minutes ago, AlexandrY said:

Не, что ни говорите, а IoT это спасение для разработчиков.

Не совсем понимаю, как сама технология IoT помогает разработке?

4 minutes ago, AlexandrY said:

ехнологии   run software-in-the-loop (SIL) and processor-in-the-loop (PIL) сильно упрощает жизнь при настройке алгоритмов управления сложной кинематикой. 

Здесь согласен!!! Сам, правда, не использовал. Но посмотрел ролики и читал статьи.

[AlexandrY 2]

24 minutes ago, haker_fox said:

Ну, а крану много-ли надо? Но даже если абстрагивароваться от крана, ПЛК же где только не стоят. Наверно не всё там так уж и примитивно.

Ну зависит от продвинутости крана.
Новые типы моторов и датчиков, новые кинематические принципы, увеличение количества датчиков, желание удешевить, повысить универсальность, усиление диагностики - все может быть против ПЛК. ПЛК же создаются из опыта типовых применений, а типовые применения не предполагают инноваций.  
А судя по постам ТС у него кран из низкобюджетной ниши, а удержать низкую цену на индустриальный продукт с учетом жизненного цикла это та еще инновация. 

1 hour ago, haker_fox said:

Не совсем понимаю, как сама технология IoT помогает разработке?

Ответ в том, что разработка крана не кончается в момент когда его установили на объекте. 

[aaarrr 63]

2 hours ago, haker_fox said:

Ох уж ваши эти шуточки Люто плюсую))))

Когда люди, не имеющие опыта в embedded linux, рассуждают о времени загрузки - это таки смищно, да.

[Д_М 0]

Спасибо за поддержку!

В подавляющем большинстве случаев, контроллер крана работает на 90%, как многоканальный преобразователь протоколов. А это самое слабое место банальных, общепромышленных PLC. PLC - это для элеваторов и котельных. Вычленить из CAN посылки полезные данные, масштабировать их, воткнуть их в MODBUS на Си дело плёвое.  Но бывают задачи на кранах, где требуется много математики, в том числе и тригонометрии. Синусы, косинусы, квадратные корни нужно считать в реальном времени. Писать свои собственные шедулеры - дело неблагодарное. Я через это прошёл. Считал его идеальным, пока не столкнулся с проблемами надёжности. Рвал на себе волосы от непонимания, что я ещё недопонимаю. К счастью, мне пришло прозрение и я нашёл один крошечный изъян. А много и не надо, чтобы система была ненадёжной. Без шедулера мои проекты работать не будут - требуется по 20 таймеров. Процессора с таким количеством аппаратных таймеров не бывает. Значит, нужны программные таймеры. Web инструментарии не рассматриваю. Вот и получается, что у меня выбор не велик - либо FreeRTOS, либо Linux. Стоит ли сразу замахиваться на Linux? Или не выпендриваться, а браться за FreeRTOS? Если последний вариант, то какой камень для этого лучше подойдёт - STM, или LPC?

[aaarrr 63]

1 minute ago, Д_М said:

Стоит ли сразу замахиваться на Linux?

Linux и реальное время - вещи слабо совместимые. И имеющиеся RT-надстройки в полной мере не обеспечивают работу в реальном времени.

 

3 minutes ago, Д_М said:

Если последний вариант, то какой камень для этого лучше подойдёт - STM, или LPC?

Любой. Смотрите, что лучше подойдет по набору периферии.

[haker_fox 60]

9 minutes ago, Д_М said:

Без шедулера мои проекты работать не будут - требуется по 20 таймеров

Вещи ортоганальные.

10 minutes ago, Д_М said:

Процессора с таким количеством аппаратных таймеров не бывает

ПЛИС?

10 minutes ago, Д_М said:

Стоит ли сразу замахиваться на Linux? Или не выпендриваться, а браться за FreeRTOS?

Завист от многого: от полного ТЗ, вашей квалификации, времени, бюджета. Если действительно только вытаскивать информацию из кана и вставлять в модбус, я бы сделал с использованием FreeRTOS, scmRTOS или ucos.

11 minutes ago, Д_М said:

Если последний вариант, то какой камень для этого лучше подойдёт - STM, или LPC?

Вы привели лишь префиксы названий МК. А среди них Cortex-M0, Cortex-M3, Cortex-M4(F). Например: stm32f051, stm32f102, stm32f407, lpc1768, lpc1788, lpc4337, lpc1825. Я бы взял lpc4337. Там есть прекрасная периферия под названием SGPIO. Из неё можно сварганить несколько аппаратных интерфейсов на подобии uart.

[mantech 34]

3 часа назад, AlexandrY сказал:

4 часа назад, haker_fox сказал:

Ну, а крану много-ли надо? Но даже если абстрагивароваться от крана, ПЛК же где только не стоят. Наверно не всё там так уж и примитивно.

Ну зависит от продвинутости крана.
Новые типы моторов и датчиков, новые кинематические принципы, увеличение количества датчиков, желание удешевить, повысить универсальность, усиление диагностики - все может быть против ПЛК.

Ооо, да, вот недавно посмотрел ролик не про краны, конечно, а карьерные грузовики какой-то забугорной конторы, так там вот видать тоже винда с какими-то приколами, плюс просчеты в механике, а клиент говорит, что чуть что и все встает колом, куча непонятных ошибок и пр... Так что все эти навороты далеко не всегда хорошо...

10 минут назад, haker_fox сказал:

Если действительно только вытаскивать информацию из кана и вставлять в модбус,

Это можно и на ПЛК сделать.

[AlexandrY 2]

7 minutes ago, Д_М said:

Вот и получается, что у меня выбор не велик - либо FreeRTOS, либо Linux. 

Начните с того какие инверторы у вас применяются и какое время отклика они могут дать.

Теперь сеанс телепатии:
Если на MODBUS-е , то скорее всего 10 мс. Т.е. инверторы из дешевой линейки, не EtherCAT. 

Так вот MATLAB Simulink Desktop Real-Time под Windows гарантирует время отклика в 1 мс!
Т.е. в 10 раз быстрее чем вам нужно. 

Поэтому самый верный путь - брать ASUS  VivoMini UN65U как edge компьютер. Ставить на него MATLAB Simulink Desktop Real-Time, делать там SIL и связывать по скоростному  Wi-Fi со своей платформой на ThreadX.  Платформа конечно должна быть Sinergy, поскольку только для нее будет бесплатный ThreadX. А ThreadX, потому что только под него найдете открытые драйвера Wi-Fi на скорость выше 70 Mbit. А 70 Mbit вам нужно, чтобы комфортно исследовать реакцию системы и управлять ею. 
Все мучения из-за невозможности наблюдать состояние системы в полном объеме.  

  

[mantech 34]

1 час назад, AlexandrY сказал:

брать ASUS  VivoMini UN65U как edge компьютер. Ставить на него MATLAB Simulink Desktop Real-Time, делать там SIL и связывать по скоростному  Wi-Fi со своей платформой

Сколь ступеней и каждая не надежней предидущей... Разве, что если надо очень быстро и никакой ответственности за сбой.

1 час назад, AlexandrY сказал:

Так вот MATLAB Simulink Desktop Real-Time под Windows гарантирует время отклика в 1 мс!

Как-то я тоже повелся на гарантию отклика винды и поставил все это в мех. привод...  А потом случайно вставил флешку во время работы...  Мех привод сразу в ремонт За-то потом был урок - реалтайм-процедуры и медленные устройства должны работать независимо...

Изменено 25 апреля, 2019 пользователем mantech

[AlexandrY 2]

26 minutes ago, mantech said:

Сколь ступеней и каждая не надежней предидущей... Разве, что если надо очень быстро и никакой ответственности за сбой.

Думаю мы о разных вещах. В мехатронике радоваться надо если вы траекторию скорости хотя бы правильную выдержали. 
Сбои никакого значение не имеют если неправильно настроены эстиматоры. Вам разбушевавшийся компенсатор столько натворит сколько ни одна флешка не сможет. Нормально же спроектировать все цепи DSP обработки можно только в развитых средах на PC типа MATLAB и только в режиме SIL.
Так что не переживайте так за Matlab. 
Потеря управления должна была у вас отслеживаться сторонними средствами. Если поленились сделать, то matlab тут не при чем.  
Потому и управление не напрямик с PC идет, а через платформу с ThreadX. 
А ThreadX имеет все сертификаты на применение в системах обеспечения безопасности.   Я думал это всем понятно. 

[jcxz 184]

4 часа назад, aaarrr сказал:

Когда люди, не имеющие опыта в embedded linux, рассуждают о времени загрузки - это таки смищно, да.

Это не смешно. Это грустно.... Когда коробочка с CPU о нескольких сотнях МГц грузится целую минуту. Всего-то лишь читая из одной быстрой памяти в другую.

2 часа назад, Д_М сказал:

Без шедулера мои проекты работать не будут - требуется по 20 таймеров. Процессора с таким количеством аппаратных таймеров не бывает.

А для указанных задач - и не нужно.