Перейти к публикации

Технические требования для покупки САПР ТП


leo-kaleta

Рекомендованные сообщения

Много лет создаются, рекламируются, продаются, эксплуатируются, совершенствуются различные технологические САПР. Эти события активно обсуждаются на этом форуме в этом разделе. И у программистов, и у дилеров, и у пользователей накоплен большой опыт.

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

Буду также весьма признателен за ссылки.

<noindex>Список технических требований.</noindex>

<noindex>Дерево технических требований</noindex>

<noindex>Участники</noindex>

<noindex>Аннотации к прикрепленным файлам</noindex>

Ссылка на сообщение
Поделиться на других сайтах


Ну вот. Прошла неделя, 50 человек прочитали мою просьбу. Никто ничего не посоветовал. Как-то неинтересно. Три года тому назад я поместил свои идеи по САПР ТП на форуме пользователей КОМПАСа в виде маленькой программки. [ skiped by admin sapr2000 ] Думал конкретное обсуждение получится. Не тут-то было. Пользователи, в основном избрали "лесную тактику". "Дайте попробовать! Дайте попробовать! Дайте попробовать!....". " Да на, бери пробуй!!!" А потом "тишина, только мёртвые с косами стоят", нет мнений, нет предложений, нет свежих идей. Не поймёшь, то ли Бревно это было, то ли Партизан. А тут что? Тоже тайга глухая?! Ау, ау. Есть кто нибудь?

Ссылка на сообщение
Поделиться на других сайтах

Понятие Технологические САПР намного шире, чем САПР ТП (под которым как правило понимают разработку маршрутной технологии изготовления отдельных деталей или изделия в целом на основании накопленных баз данных). Регламентирующие документы - есть ГОСТ довольно старый(номер уточню на работе) по оформлению различных технологических карт ТП, созданных автоматизированным способом. А покупают ПО, подварительно взяв в опытную эксплуатацию и проводят анализ совместимости с имеющимися программными средствами на предприятии, решаемыми задачами и своим собственным видением "как это должно быть".

ЕСТД ГОСТ 3.1129-93.

Общие правила записи технологической информации в технологических документах на технологические процессы и операции.

и ряд ГОСТов: 3.1001-81 и т.д. для оформления и содержательной части документов.

Ссылка на сообщение
Поделиться на других сайтах

Если ограничиться только автоматизацией разработки технологических процессов, то все что надо это обеспечить примерно следующий процесс:

1. Разработка маршрута изготовления(сборки)

2. Определение опраций

3. Разработка переходов операций

4. Вывод технологической документации.

И здесь как бы требования все изложены в ЕСТД.

Но, самое интересное в том, что любое ПО именно описывает все только в рамках ЕСТД, а если нужно отойти, то тут практически всегда приходиться идти на компромисс между тем как сейчас принято на предприятии и тем что есть в ПО.

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

Из моего опыта можно не выдвигать требования к ПО перед покупкой, а сделать следующим образом:

1. Подготавливается 1-2 детали с готовыми техпроцессами, написанными так как это принято на предприятии.

2. Объявляется тендер по выбору ПО для автоматизации работы технологов. Приглашаются все известные производители ПО, их не так много.

3. Во время проведения тендера делается следующее:

3.1. каждому представителю представителю выделяется компьютер, желательно совершенно

новый. Он сам устанавливает ПО.

3.2. каждому дается одно и тоже задание вот чертеж детали на который надо сделать

техпроцесс, выделяется технолог который помогает в создании техпроцесса(точнее в

перекладке техпроцесса, например, из бумажного вида в электронный).

3.3. По каждому ПО выводится комплект технологической документации. При этом естсетвенно

представитель ПО доделывает имеющиеся в ПО бланки под требуемый вид

3.4. По окнчаании технолог описывает свои замечания и наблюдения, ожно даже опросить

технологов и заранее составить перечень того что должен содержатть техпроцесс

окончательно, и какие особенности должны быть реализоываны при автоматизировнном

создании техпроцессов.

Чтобы совсем было хорошо, нужно для каждого представителя ПО выделить один день и в этоот день больше никого не приглашать. И желательно чтобы одна и та же группа технологов участововала во всех тестированиях.

По окончании этого процесса делайте выводы какое ПО вам нужно и что требуется дорабоать в том или ином случае.

Я сам в таком не участвовал просто слышал и разговаривал с организаторами такого.

Последние 3 года мне как раз приходится заниматься автоматизацией разработки технологических процессов на одном из предприятий. По используется как покупное так и собственной разработки.

Изменено пользователем labslo
Ссылка на сообщение
Поделиться на других сайтах

Если ограничиться только автоматизацией разработки технологических процессов, то все что надо это обеспечить примерно следующий процесс:

1. Разработка маршрута изготовления(сборки)

2. Определение опраций

3. Разработка переходов операций

4. Вывод технологической документации.

Ну если речь идет только об этом, то скорее всего это могут (так или иначе) все сапртп без исключения.

Но боюсь, что это далеко не все, что нужно.

Потому, как основное приемущество сапртп это не сам тп в его печатной форме, а то, какую информацию можно из него получить для дальнейшй работы, и сколько усилий надо потратить на ее получение в том числе и в электронной форме.

И самое главное это не купить программу, а заставить ее работать в полном объеме. Потому в добавок к покупке надо сразу подумать о дальнейшем обучении, сопровождении и доработке под ваши требования. Если этого не предусмотреть - то заставить программу работать в полном объеме будет достаточно тяжело.

Еще на основе личного опыта, могу сказать, что с любой из проограмм можно добиться как положительного, так и отрицатльного результата. И пока вы сами реально не поработаете с программой, вы не сможете ее оценить (какой бы список требований вы не составили). Потому соглашусь с Еленой обращайтесь к производителям и берите у них пробные верси. Попробуйте своими руками, применительно к вашеу предприятию (лучше предварительно пройти обучение) - а только после этого можно говорить о покупке. И так желательно протестировать не одну программу.

Ссылка на сообщение
Поделиться на других сайтах

Елена. Большое Вам спасибо за развёрнутое интересное сообщение. К Вашим словам хотел бы добавить: "Я очень люблю читать ГОСТы, потому что это стержень нашей работы". Особенно мне нравится ГОСТ по оформлению техпроцессов. Там есть две очень интересные для меня идеи.

Во-первых - это идея составления оформительской формы из модуль-блоков, а во-вторых. это возможность вставки на один лист записей совершенно разных форматов, которые кодируются буквами А, Б, Р... По сути это те же КТЭ, та же многовариантность и геометрическая прогрессия.

Ещё раз спасибо, Елена.

С уважением, Леонид.

Labslo. Спасибо Вам за совет, как выбирать для покупки САПР. Я уже один раз в таком учавствовал. Мы организовали семинары с тремя разными фирмами-конкурентами, потом подумали, выбрали и купили соответствующее ПО. Это очень нужная работа. На семинаре выступающий выкладывается полностью до последней капли, его речь окрашена эмоциями. А живая речь намного быстрее доходит, чем размытые "водой" рекламные проспекты. Я считаю, что это вообще "сладкий сироп". А иногда я делаю так, еду на семинар, пишу подробный смысловой конспект выступлений, потом печатаю многостраничный отчет о командировке. Вся толпа с удовольствием читает, и начальству тоже очень интересно.

А все-таки я хотел бы почитать какие-нибудь технические требования. Любые требования - это всегда интересно. Вспомним самый известный список требований : "Чтоб не пил, не курил, деньги чтоб домой носил..." У каждого пользователя за долгие годы что-то накопилось, что-то есть. Пожалуйта не молчите, скажите что-нибудь!!! У меня тоже есть небольшой список требований к САПР ТП. Я бы хотел бы его тут огласить (понемножку, по одному) и хотел бы по каждому пункту услышать мнения.

Пункт 1. Мой опыт показывает, что иногда бывают проблемы из-за применения шрифтов где цифра "0" похожа на букву "О", цифра "3" похожа на букву "З", цифра "4" похожа на букву"Ч", цифра "1" похожа на букву "7", ... Я считаю, что технологическая документация очень близка к бухгалтерской, всё связано с зарплатой десятков миллионов людей. Всё должно быть однозначно. Должен быть однозначный шрифт. Если мне такой порекомендуют, то буду очень рад.

Формулировка требования: "Технологическая САПР должна иметь шрифт, в котором ни один символ не может быть похож на любой другой".

Жду ответов.

Ссылка на сообщение
Поделиться на других сайтах

Юмор ценю.

А вообще техтребования зависят от того, какую Вы перед собой ставите задачу.

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

Кроме того иногда чтобы поставить задачу нужно перелопатить очень много документов. А для того, чтобы получилось и было Вами понято, то эту работу придется проделать самому.

Ссылка на сообщение
Поделиться на других сайтах

Елена, спасибо за новое сообщение.

Я почувствовал, что не зря зашёл на этот форум и что-то начал спрашивать. Вот прошлый раз забыл поблагодарить Kostik00 за дельный совет "брать на тестирование пробные версии и желательно не одну". Виноват, спасибо Kostik00!!! Ваше предложение полностью исключает ситуацию "купить Кота в мешке". Ведь все знают, что можно поспешить и купить такого Кота, а потом приходится с помощью усиленного питания, тренировок и консультаций делать из него Рабочую Лошадь. Согласитесь, что это очень тяжело и для Кота, и для Покупателя.

И всё-таки мне хочется "добыть" здесь какую-нибудь новую информацию по моей теме "технические требования для покупки САПР ТП". Вот по пункту 1 прочитал свою формулировку и что-то она мне не понравилась. Как-то коряво. Можно придраться и сказать "символы и так не похожи друг на друга". Может кто поможет сформулировать мой первый пункт ТТ пограмотней? Коллеги, помогите пожалуйста!

И, признаться я ожидал вопроса: "Ну а чем вам ГОСТовский шрифт не нравится?" Я на всякий случай отвечу. В том то и дело, что мне очень нравится ГОСТовский шрифт. Он очень красивый. Помню, мы как-то вели совместные работы с одной зарубежной фирмой по модернизации самолёта бизнес-класса. Что нас шокировало, это то что 30% денег Они тратили на внешний вид своего самолета!!! Товар надо показать лицом и продать. Это я к тому, что те фирмы, которые использовали в своём ПО ГОСТовский шрифт конечно же очень сильно выиграли на рынке за счёт внешнего вида документации. Поэтому я двумя руками за этот шрифт, но плюс необходимые дополнения, делающие его однозначным. Все хорошо знают "перечёркнутый ноль" и "семёрку с чёрточкой". Надо эти идеи развить дальше.

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

Ссылка на сообщение
Поделиться на других сайтах

Так о чём идёт речь? Что такое САПР ТП? Что понимать за этой абревеатурой?

Сиситема автоматизированного проектирования тех-процессов. Автоматизированного насколько? Проектирования какокое, вернее с какой степенью детализации?

Указав маршрут движения детали по цехам предприятия это не есть уже описание техпроцесса?

Сейчас многие начнут возрожать, что конечно же это не является ТП. Что ТП - это что то более подробное, так вот насколько подробное? Можно расписывать до операций, а может до переходов, а может в каждом переходе надо ещё что то детализировать? Где начинается и где заканчивается проектирование ТП? Пожалуй на этот вопрос каждый конкретный потребитель ПО должен ответить себе сам, что и в каком обьёме он собирается расчитывать и описывать, какие документы ему действительно будут нужны и в каком виде? Исходя из этих посыло нужно и выбирать ПО.

Я думаю, что не открою большую тайну, сказав, что в большинстве случаев, на многих предприятиях, комплекты технологических документов, как правило, пыляться в архивах и извлекаются оттуда очень редко в случае возникновения каких либо спорных вопросов или если что то совсем подзабыли. Покажите мне хоть один завод, где токарь или фрезеровщик, слеарь или кузнец вместе с заданием (нарядом) и чертежём получает (берёт) на рабочее место ешё и комплект ТД. :blink:

Стоит ли так остро вопрос "ГОСТовский шрифт" или нет, бланки карт формы А или формы Б? По моему мнению, намного важнее какой информацией наполнена база данный ПО, насколько удобно её исспользовать потребителям этой информации, начиная от планово-экономических служб, снабженцев, производственников и закнчиваю службами тех.контроля.

Стоит задуматься, для кого и для чего готовиться вся эта информация технологами. Только лишь для печати различных карт ТП с ГОСТовским шрифтом? Или же всё таки эта информация нужна непосредственно для организации, подготовки и осуществления самого процесса производства. В конечном итоге веть нужно произвести товарную продукцию и продать её, если только вы не инжениринговая компания и не занимаетесь разработкой ТП для сторонних заказчиков и ваш товар это и есть бумажный комплект различных технодогических карт :g: .

Ссылка на сообщение
Поделиться на других сайтах

Здравствуйте, всем привет. Спасибо за сообщение и вопрос про базы данных. Давайте поговорим об этом. Придётся обращаться за помощью к специалистам. Но сначала немножечко приправы, потому что даже макароны без неё есть тяжело.

Козьма Прутков говорил:"Каждый специалист подобен флюсу, полнота его одностороння". И это было сказано задолго до появления ядерного оружия и компьютеров! Давайте разовьём эту мысль.

Случай первый - лёгкий. Моя вторая тёща долгое время работала учителем начальных классов и к тому же где-то прочитала, что мужчины и женщины мыслят по-разному. У первых попеременно работает то левое полушарие, то правое, а у женщин всегда "включены" оба полушария. Поэтому глубокое убеждение моей тёщи - "Все мужчины - дети". И вот она почти каждый день моей Дорогой и Ненаглядной говорит - "Вот он - ну такой ребёнок, а вот они - ну такие дети, а этот тоже ребёнок, и этот тоже." И они вдвоём - "А вот мы женщины, мы такие умные". А я, чтобы восстановить душевное равновесие вспоминаю свой любимый анекдот: "Один мужик не ладил со своей тёщей. И вот она умерла. Все пошли в церковь её отпевать. Мужик оттуда выходит и тут птичка. Он лихорадочно, быстро вытирает лицо, злобно машет руками и орёт: "Ах, ты опять за своё!!!"

Случай второй - средней тяжести. Всегда хорошо, когда люди с юмором. Я вот как-то к своим знакомым программистам зашёл. Они, чтобы не заноситься, на стенке большой плакат повесили "Если бы строители строили свои дома так же, как программисты делают свои программы, то первый залетавший дятел разршил бы цивилизацию". Но так бывает не всегда. Однажды наблюдал диалог программиста с конструктором. Один :"Сбалансированное В-дерево поиска". Другой: "Неуказанные предельные отклонения размеров плюс-минус IT14 пополам". Друг друга не понимают, злятся. Конструктор ушёл, программист мне жалуется:" Ну почему конструктора такие тупые?" Я потом в цех защл, разговариваю с конструктором, а он говорит:"Ну и тупые же эти программисты".

Случай третий - тяжёлый. В воскресенье гладил брюки, слушал радио (какую-то передачу о здоровье). И тут началось. Хорошо что диван был рядом и утюг из розетки успел выдернуть. Стоя это слушать было невозможно. Называется "обстинентный обной сна". Почему почти? Потому что всё-таки было одно понятное слово "Храп", перед которым было выражение "А обычные люди называют это..."

Петросян жалуется, что материала мало. Да посмотри,что кругом творится. Юмористымогут отдыхать.

Вывод: современный мир взрывообразно усложнился, поэтому все мы без исключения стали специалистами. А вот, что будет, если мы продолжим гордиться своими обширными знаниями, написано в библейской притче о Вавилонской Башне.

Ну а теперь я хочу продемонстрировать своё наивное представление покупателя о технологических базах данных, для того, чтобы специалисты могли всё это разбить в пух и прах и сказать, как правильно.

Этот раздел технических требований я бы назвал "Информационный склад технолога".

Понятно, что информациюнадо где-то хранить и как-то с ней работать. Сначала для этого использовали файлы. Например, всем известные текстовые и двоичные. В певых информация считывается по строкам, если ёё много, то пока доберёшься...... Во-вторых уже легче, можешь скакать, как горный козёл по всему файлу, используя адреса. Но возможностей у файлов оказалось мало, потому что одна и таже информация нужна одновременно разным людям. Поэтому появились базы данных. И системы управления ими. Сокращнно СУБД - системы управления базами данных. Сначала были "инвентированные списки", потом появились иерархические СУБД. Кстати на этом форуме информация тоже накопилась и начались ветвления - подфорумы. А потом новый этап - "сетевые" СУБД. На самом деле жизнь -это сеть. Однажды, чтобы правильно изобразить все связи конструкторского узла мне пришлось создать информационную структуру, которую я условно назвал "дерево, опутанное паутиной". А потом все эти виды ранних СУБД были вытеснены реляционными СУБД и вот почему. В реляционных СУБД основной единицей хранения информации является "отношение" (это совсем непонятно), назовём это "таблицей" (это скучно и неинтересно и тоже не очень понятно). Я называю это "матрица", потому что у всех в голове после фильма "Матрица" возникает яркий ораз матрицы и всем всё понятно. И реляционные СУБД всё вытеснили именно за счёт своей системы матриц, с которыми легко работать с помощью реляционной алгебры. Но окозалось, что в области САПР и искусственного интеллекта реляционных СУБД недостаточно, слишком сложные вещи приходится строить вручную. Поэтому на смену реляционным СУБД приходят постреляционные СУБД, в которых есть "старые" иерархические и сетевые методы, но остаётся реляционная алгебря. А мне например, очень интересны семантические (то есть написанные на понятном для пользователя языке) СУБД, которые с помощью автоматического анализа и ER-методов конвертируются в удобный реляционный вид. Также понятно, что мы накуда не уйдём отязыка SQL и архитектуры "клиент-сервер". Это уже классика.

Жду от специалистов раздел понятных для покупателя технических требований посвящённый хранению и поиску информации. Граждане подходим: "Брёвнышко взяли, понесли. Веселее, веселее..."

Ссылка на сообщение
Поделиться на других сайтах

Здравствуйте.

Прошла неделя, но пока никто ничего дельного не сказал. Жду и надеюсь, что это всё-таки произойдёт. "Надейся и жди - вся жизнь впереди".

Ну ладно. Пока заполним паузу рассуждениями о том "нужна нам технология или не нужна". Тут некоторые сомневаются, - "мол, пылится на полках". Как Гамлет: "Быть или не быть? Вот в чём вопрос".

А давайте посмотрим, что происходило на нашей планете в последние семь тысяч лет. Вначале было много мелких племён, которые воевали между собой и которыми командовали вожди. А вот почему племена были мелкие? А вот попробуйте, пользуясь своей глоткой и кулаками скоординировать действия, ну хотя бы 100 человек. Даже для племени такого мелкого масштаба нужен вождь, обладающий огромной физической силой и зычным голосом (да и то - осипнет).

И вот 7 тысяч лет назад в Египте появилась письменность. Что произошло в результате? Правильно! Возник огромный социальный организм - государство. С очень развитой (для того времени) информационной структурой. Значит - просто язык и речь позволяют объединить в одну команду 100 человек. Письменный язык и речь увеличивает эти возможности, и в одной команде уже миллион человек.

А что произошло дальше? А дальше Гуттенберг где-то в 1450 году (точно не помню) изобрёл печать. И это европейское изобретение породило множество европейских сверхдержав - колониальных империй, количество населения в которых иногда доходило до миллиарда человек.

А сейчас есть компьютеры и Интернет и даже дураку понятно, что мы стали одним суперорганизмом.

Отсюда следует, что средства распространения и носители информации играют свою ОГРОМНУЮ роль в жизни человечества.

Ну, а теперь о специализации. Понятно, что когда каждый занимается своим делом, и всё это скоординировано по технологическим операциям, то всем жить легче. Наооборот, когда "лягушата крякают, а утята квакают", то "крокодил не ловится, не растёт кокос".

Нас учили, что первые мануфактуры появились в Англии. Но это не так! На самом деле первым ТЕХНОЛОГОМ был отец Александра Македонского. Первой мануфактурой была македонская фаланга, которая, как "нож сквозь масло" прошла через огромные толпы героев. И даже римский консул, который её победил, благодаря счастливому случаю и неровностям местности, с нескрываемым ужасом (даже спустя много лет) вспоминал эту грозную боевую машину.

В конной лаве Будённого тоже была специализация и разделение работы по операциям. В первом эшелоне скакали опытные рубаки, их прикрывали меткие стрелки второго эшелона, третий эшелон новичков-учеников зачищал то, что осталось от первых двух, чтобы никто не мог напасть с тылу.

Это примеры того, что даже простая специализация даёт заметные результаты.

Ну а теперь - моя классификация предприятий и организаций. "По историческому развитию средств информации".

Предприятия первого типа - информационная структура: "Племенной вождь". Командный состав этих организаций ходит с осипшими голосами. Кулаки разбиты (иногда забинтованы), ноги болят от раздавания пинков.

Организации типа 2 - "писари". У этих между пальцами рук натёрты мозоли, языки и губы синие от пасты авторучек, иногда что-то написано на ладони. Очень много всяких нарядов, журналов и путевых листов. Самый яркий пример - это наши поликлиники.

Предприятия типа 3 - "бюрократы". Много документации, на ней много подписей и печатей. Документация интенсивно размножается. Много всяких согласований и разрешений. Любимые фразы персонала: "перевести стрелку", "отвести ..."

Предприятия типа 4 - "хакеры". У всех под глазами синие круги, глаза немного светятся, волосы распушены от электростатики, выражение глаз - тупое (от долгого сидения за компьютерами).

Короче - я считаю, что "не нужна" технология, которая выполнена не в срок, с ошибками, не оптимально, с перерасходом денег, то есть вручную. И очень нужен технолог, вооружённый САПР ТП. Себестоимость таких документов ниже, качество выше и пользы больше.

Ссылка на сообщение
Поделиться на других сайтах

себестоимость документов? интересная мысль...уместнее все-таки длительность разработки, нормо-часы если хотите

технические требования: посмотрите на имеющуюся CAD у конструкторов, и если она уже есть, то выбора как такового не останется

Ссылка на сообщение
Поделиться на других сайтах

1. Нормальное предприятие не может являться нормальным без технологии (хотябы на уровне ДМК). Потому как без нее нельзя сформировать нормальный план - нет нормального плана - нет нормального договора - соотв. нет нормальной оплаты.

2. Глубина детализации после уровня ДМК очень редко требует большей детализации, чем текстовое описание. (разве что изредка еще необходима информация о вспомогательных материалах и инструменте)

3. Оформление ТП вообще не является принципиальным вопросом потому, как участь красиво оформленых многостраничных ТП - уже упоминалась выше (лежат на полке). Да и большинство вопросов в области оформления как правило являются надуманными (и очень легко решаются).

4. Когда вы перестанете рассматривать САПРТП как отдельно взятую программу для рисования техпроцессов?

5. Как вы представляете автоматизацию написания ТП, и чем она отличается от копирования уже имеющегося ТП и последующей его корректировки?

Как разработчик программы - <noindex>http://istpp.krasnov.org</noindex> по поводу технологии разработки ПО скажу следующее:

1. Пользователю все равно какими технологиями работает программа и как достигается результат (Будь то реляционная БД либо любая другая). Я думаю для пользователя гораздо важнее, чтобы при нажатии на кнопку формирования отчета, он формировался быстро (желательно сразу), да и при сохранени изменений и прочих операциях время отклика должно быть как можно меньше.

2. На данный момент все технологии ведения БД, кроме реляционной(SQL) до сих пор не имеют достойной реализации - соответственно достойной альтернативы SQL действительно пока нет. И работать вы скорее всего будете с SQL, все другиее варианты будут уступать как минимум в скорости.

3. В форумах программистов на вопрос какая технология лучше - ответ один - та, которой ты умееш пользоваться - так что если программа написана не неизвестном языке, использует неизвестную БД, но при этом будет выполнять поставленные задачи быстро и недежно, то вряд ли стоит от нее отказываться потому, что вы ничего не слышали о данной программе, языке, субд... Сосредоточтесь лучше на определении списка задач, ну и давайте их сюда (обсудим).

Ссылка на сообщение
Поделиться на других сайтах

Поддерживаю Kostik00. Давайте прекратим молчать и нормально всё обсудим.

А теперь о молчащих. В XIX веке в Москве и Петербурге тоже был своего рода "Интернет". У светских барышень были альбомы, в которые они просили что-нибудь записать-нарисовать приходящих к ним гостей. И вот однажды к одной барышне пришли два кавалера. А она им бах - альбом в руки. А у них в голове ничего нет. Они сидели-сидели и придумали. И написали: "Под деревом бананом сидели два барана и думали о том, что написать в альбом".

Мне после этого хочется сказать: "Так выпьем же за то, чтобы нам всегда было чего записать".

Люди - не надо быть баранами, давайте оживайте же в конце концов!!!

Ссылка на сообщение
Поделиться на других сайтах

Поддерживаю Kostik00. Давайте прекратим молчать и нормально всё обсудим.

Ну вообщето вы не совсем меня правильно поняли.

Говоря "обсудим" я предлогал обсудить ваши проблемы, если они у вас конечно есть.

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

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

Ссылка на сообщение
Поделиться на других сайтах

Доброго времени суток, Господа!

Давольно давно слежу за форумом и не могу взять в толк одного: на мой непросвещённый взгляд, под САПР ТП понимаются совершенно разные вещи. Это не только к посетителям форума и уважаемым участникам. Это, в первую очередь, к продавцам и разработчикам относится. Ну и к покупателям.

А именно, столкнувшись с необходимостью оснащения нашего производства САПР ТП начал с разработки бизнес процессов и понял, что надо ТРИ разных вещи, а то и 4, называемых САПР ТП.

Для одного случая нужна грубая маршрутная технология с предварительным нормированием (например для оценки себестоимости и сроков изготовления), для другого и в другое время - точная (для планирования мощностей и закупок, загрузки оборудования), потом, совершенно в другое время (иногда раньше, иногда позже) - операционная, а иногда - тщательнейшая проработка режимов неапример , резания. Иногда ещё САЕ подключить бв не мешало, чтобы оценить деформацию детали на станке.

Кстати, всё это ГОСТами описано, и не очень дурно. Форма представления ГОСТовская - ну.... ну не самое это страшное в жизни.

Толком реализующую все три (четыре) функции прогу так и не увидел. Может плохо искал? Но честно старался. :surrender:

Ссылка на сообщение
Поделиться на других сайтах

Давольно давно слежу за форумом и не могу взять в толк одного: на мой непросвещённый взгляд, под САПР ТП понимаются совершенно разные вещи.

Именно так и получается - потому и разговор не клеится. Обычно вся проблемма в использовании такого рода программного обеспечения кроется в том, что пользователь при покупке еще сам не знает, что он хочет (ну или покупает не тот, кто работает потом на этй программе). Это особенно важно при покупке монстрообразных систем, потому как для одного пользователя /предприятия они поворачиваться не будут.

Для одного случая нужна грубая маршрутная технология с предварительным нормированием (например для оценки себестоимости и сроков изготовления), для другого и в другое время - точная (для планирования мощностей и закупок, загрузки оборудования), потом, совершенно в другое время (иногда раньше, иногда позже) - операционная, а иногда - тщательнейшая проработка режимов неапример , резания.

Вот это уже ближе к делу. От заказчика как правило требуется определить насколько ему важны эти самые этапы и насколько он хочет это все детализировать.

Только после того, как список требований определен, можно смотреть насколько существующие программы удовлетворяют требованиям.

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

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

Ссылка на сообщение
Поделиться на других сайтах

Спасибо Zubryonook за классификацию необходимых в производстве САПР ТП.

Ёще раз убедился, что я правильно сделал, что перестал молчать и начал задавать вопросы. Результат уже чувствуется - в башке всё начинает становиться на свои места.

Лев Толстой говорил, что люди все "пёстрые". А мы и в самом деле "пёстрые". Кто-то одни вопросы знает очень сильно, а другие слабо, другой - наоборот. У каждого - свой спектр, со своими пиками и впадинами. И только общение, обсуждение позволяет суммировать это богатство. Вот почему так нужны форумы.

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

А можно продавать разные САПР ТП, закрывая разные ниши рынка, по широко известному принципу: "Вчера были маленькие, но по три, а сегодня большие, но по пять, но сегодня...". В этом случае нам, покупателям, нужна информация - к какой весовой категории относится та или иная САПР ТП.

Прошу не оставлять мои сообщения без ответов, потому что ответы - это опора, по ним видно, что надо делать. Надеюсь на помощь и поддержку. Жду комментариев.

Ссылка на сообщение
Поделиться на других сайтах

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

Ну что касается шрифтов по госту, то я уже высказывался, тем более что по госту допустимо даже печатать ТП на АЦПУ. А что касается других требований, то я их почемуто не заметил, зато куча воды в том числе и про Льва Толстого в изобилии.

Кстати я еще не смог найти ничего о программе, которую ты написал. Если не трудно, то дай пожалуйста ссылку.

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

Еще раз повторюсь, что программы писать не сложно, сложно найти заказчика, который знает, что он сам хочет, и готов пойти на решительные меры для достижения этой цели. Потому как показывает практика, написание программ, происходит гораздо быстрее их внедрения (соотношение 2-4 месяца/6мес-бесконечность). При этом такие программы, как САПР ТП, на предприятиях, где количество технологов переваливает за 15-20, могут внедряться годами. А это всего лиш маленький этап в комплексной автоматизации предприятия.

Ну и про тех требования, еще раз прошу уменьшить простор для фантазии, и перейти к обсуждению более приземленых вещей. В качестве основы для твоих техтребований возьми хотябы раздел "Конструкторско технологическая подготовка производства" на моей страничке <noindex>http://istpp.krasnov.org</noindex> ну и давай дополни его нужными с твоей точки зрения пунктами. После этого огласи и уж тогда задавай вопросы - будет хотябы от чего оттолкнуться.

PS: Очень интересно, какие ты сможеш составить требования к справочникам, особенно требования к справочнику материалов(сортамента). Еще очень важные вопросы взаимодействия с другими программами/системами (схема прохождения документов итд).

Ссылка на сообщение
Поделиться на других сайтах
  • 2 недели спустя...

Считаю, что продавец не имеет права говорить покупателю "ты" даже в критические дни, даже когда "и скучно, и грустно, и некому морду набить в минуту душевной невзгоды". Покупатель это не деревянный столб, а человек. Значит в голове у него есть полезные требования и идеи. Например, моя идея - объединять файлы в подшивки, впервые использованная в 1999 году в бесплатном редакторе типовых расчетов "Айсберг", сейчас применяется в широко известной САПР (только версией LT этой САПР пользуются более 1 миллиона человек по всему миру).

Интересно, а у Вас есть идеи мирового уровня?

Теперь насчёт Вашего требования "огласить полный список". Прошу ещё раз внимательно прочитать моё первое сообщение в этой теме. С момента его появления прошло уже 2(!!!!) месяца. Согласитесь, что Вы немножко пожадничали. Если бы Вы сразу дали свою ссылку, то и "воды" было бы меньше. А можно мне немножечко пожадничать в ответ. Можно я скажу "...На мясокомбинат ... сегодня нарядов нет". Тема моя, и всё будет проходить в том темпе, который я выбрал.

И так. На сегодняшний день список ТТ для покупки САПР ТП "подрос" до 4-х пунктов.

Перечислю:

1. Однозначный шрифт - идея "перечёркнутый ноль".

2. Должна быть разница между латиницей и кириллицей. Я, кстати, не возражаю против разного цвета. Можно сам шрифт не трогать.

3. САПР ТП должна быть выполнена по принципу всплывающего айсберга. Если Вы внимательно прочитаете этот раздел форума, то увидите что некоторые САПР ТП уже так и продают.

4. В САПР ТП "лёгкой" весовой категории должны использоваться подшивки файлов.

Ну что, может всё-таки, наконец, нормально обсудим эти конкретные вопросы - а потом пойдём дальше?

Считаю, что продавец не имеет права говорить покупателю "ты" даже в критические дни, даже когда "и скучно , и грустно, и некому морду набить в минуту душевной невзгоды". Покупатель - это не деревянный столб, а человек. Значит в голове у него есть полезные требования и идеи. Например, моя идея - объединять файлы в подшивки, впервые использованная в 1999 году в бесплатном редакторе типовых расчётов "Айсберг", сейчас применяется в широко известной САПР, одной версией LT которой пользуются более 1 миллиона человек по всему миру.

Интересно, а у Вас есть идеи мирового уровня?

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.
Примечание: вашему сообщению потребуется утверждение модератора, прежде чем оно станет доступным.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




  • Сообщения

    • lem_on
      ну с дуру известно что сломать можно.
    • Viktor2004
      руку привязки так сломать легко
    • lem_on
      По моему вполне логично если станок вывалится в ошибку если рука не доехала до места. У меня так же если кулачки или деталь на пути, просто пихаеш ее до места и станок опять активен. Но нынешние пановья даже не могут написать модель станка.
    • Viktor2004
      Я согласен что скорее всего проблема механическая Но если логика прописана криво и возможно не предусмотрела остановку в промежуточном состоянии, разве не логично будет попробовать принудительно подав напряжение дернуть эту руку вверх-вниз? Возможно то что туда попало выпадет  
    • Guhl
      Если оставить за скобками вопрото том, что до м19 работает нормально, а после нет, то вы не считали сколько у него реально импульсов на оборот? с помощью стороннего плк, например  А если ориентацию м5 снимать, а не м20?
    • lem_on
      Что это за станок такой в котором сразу ладер ковырять надо, даже не смотря на возможность механической проблемы? Или профдеформация?
    • Viktor2004
      не сразу я понял в чем вопрос. Долго соображал что такое режим управления скоростью. При завершении ориентации PMC снимает сигнал G70.6 ? И если он после снятия сигнала продолжает удерживать шпиндель, при каких условиях эта ориентация все же снимается? После нажатия аварийного грибка или еще как?
    • Viktor2004
      Ладдер пришлите. Будем принудительно пробовать поднимать и опускать
    • streamdown
      Коллеги приветствую! IPS 8. Подскажите пожалуйста, кто какое серверное железо использует? Интересуют параметры при одновременной работе, ну например, 400 пользователей онлайн
    • gudstartup
      так он так и позиционируется по m19 pmc выдает g70.6 а чпу отвечает f45.7 но ориентацию и смещение в 4077 он отрабатывает нормально шпиндель встает ровно и смена происходит хорошо. вопрос почему после ввода команды управления скоростью он все еще продолжает контролировать число импульсов между нуль метками хотя в принципе уже должен отменить позиционный контроль и просто считать обороты по 0 метке как он это делает без М19? это все понятно но почему оно продолжает проверять это после завершения ориентации мне непонятно
×
×
  • Создать...