Processing Solid Edge objects

[Maria R]

I consider using Python to process Solid Edge .par .asm etc objects.
Solid Edge provides a pretty rich documentation and tutorials.
Still, when trying it out, using PyWin32, I get somewhat frustrated.

So, I hope for someone out there to be willing to share experiences.

The objective is to automate generation of customer specific machine
elements from project spec's.
In particular, we wish to be able to use .par files as templates and,
by
taking a copy and changing attribute values, instantiate components
to be used in an assembly.
The end result shall be a complete construction structure from which,
among many things, customer doc's drawings and Bill Of Materials are to
be
extracted.
//M

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Processing Solid Edge objects

[Maria R]

olive skrev:

> It would help if you could give an exemple of .par and .asm file.
>
> Is it human readable, XML ... ?
>
> Is there any other import/export file format provided ?
>

The .par files and friends are in binary format so the method I prefer
is
using the provided COM interfaces and access the various objects that
way.

Therefor I seek advice from those who have tried this so I may decide
whether
I shall pursue the Python trail or go for some other language like VB
or C# where
there are code samples.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Who uses Python?

[Maria R]

I tend to agree with some earlier poster that if you use Python you
are, in a sense, a programmer :o)

But seriously, we use Python for controlling fully automated logistics
solutions (conveyors and stacker cranes), for generating PLC code etc
etc.

We are also about to start using FactoryCAD (a thingy from UGS to run
on top af AutoCAD) in which we have "intelligent" objects. These
objects have action code and FactoryCAD contains an embedded Python
interpreter. Our mech engineers thus write (although a bit simple but
still..) Python to make things work :o)

We further have generators of mechanical assemblies in SolidEdge. We
use a rule based approach and both the configuration files and the
rule base are in Python. Our Mech engineers maintain that too.

My two cent..


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is deployment?

[Maria R]

On May 20, 7:28 am, Paul Rubin  wrote:
> Ben Finney <[EMAIL PROTECTED]> writes:
> > Agreed. I usually discuss "deployment" as meaning "everything required
> > to take something from the point of working in a vendor's lab
> > environment, to an actual working installation in a production
> > environment".
>
> I'd go beyond that.  It includes putting the people and procedures in
> place for keeping the production system operating, upgrading it as
> needed, customer support, the whole bit.  It's all the stuff that
> happens on the other side of the line separating "development" from
> "operations".

I would suggest a somewhat more limited view.
That is, deployment is the process after development is finished (or
the product system is purchased) up until it is in full operation
(including establishing support organisation etc).
The exact point of time is, of course, not very clear cut.
Upgrading the product, adding more users, extending the use etc. is
not, as I see it, *deployment*.
But then again, one could say that an upgrade is deployed. However, I
prefer to view that as a separate project with its own process.

-- 
http://mail.python.org/mailman/listinfo/python-list

comtypes CreateObject problem

[Maria R]

We get the following, less favourable respons :o(
Any advice is greatly appreciated!!

Setting is python 2.5.2, windows xp professional SP3, SolidEdge V20
SP10

We have success with comtypes interfacing other software like SmarTeam
(PDM/PLM software) and of course Excel and alike.

Thnx

IDLE 1.2.2
>>> import comtypes.client
>>> foo = comtypes.client.CreateObject("SolidEdge.Application")
# Generating comtypes.gen._8A7EFA3A_F000_11D1_BDFC_080036B4D502_0_1_0
# Generating comtypes.gen._00020430___C000_0046_0_2_0
# Generating comtypes.gen.stdole

Traceback (most recent call last):
  File "", line 1, in 
foo = comtypes.client.CreateObject("SolidEdge.Application")
  File "C:\Python25\lib\site-packages\comtypes\client\__init__.py",
line 204, in CreateObject
return _manage(obj, clsid, interface=interface)
  File "C:\Python25\lib\site-packages\comtypes\client\__init__.py",
line 165, in _manage
obj = GetBestInterface(obj)
  File "C:\Python25\lib\site-packages\comtypes\client\__init__.py",
line 102, in GetBestInterface
mod = GetModule(tlib)
  File "C:\Python25\lib\site-packages\comtypes\client\_generate.py",
line 112, in GetModule
mod = _CreateWrapper(tlib, pathname)
  File "C:\Python25\lib\site-packages\comtypes\client\_generate.py",
line 188, in _CreateWrapper
mod = _my_import(fullname)
  File "C:\Python25\lib\site-packages\comtypes\client\_generate.py",
line 26, in _my_import
return __import__(fullname, globals(), locals(), ['DUMMY'])
  File "C:\Python25\lib\site-packages\comtypes\gen
\_8A7EFA3A_F000_11D1_BDFC_080036B4D502_0_1_0.py", line 3393, in

( ['in'], POINTER(_midlSAFEARRAY(c_char)), 'Accelerators' )),
  File "C:\Python25\lib\site-packages\comtypes\safearray.py", line 18,
in _midlSAFEARRAY
sa_type = _make_safearray_type(itemtype)
  File "C:\Python25\lib\site-packages\comtypes\safearray.py", line 52,
in _make_safearray_type
raise TypeError(itemtype)
TypeError: 
>>>
--
http://mail.python.org/mailman/listinfo/python-list

Re: C++ or Python

[Maria R]

On Jun 28, 12:22 am, Kurda Yon <[EMAIL PROTECTED]> wrote:
> I would like to know what are advantages of Python in comparison with C
> ++? In which cases and why Python can be a better tool than C++?
>
> Thank you!

Back in 2002, we made a hard decision between c++ (well established
here) java (not as mature back then) and python (completely new to my
company).
The task was to do a complete rewrite of our control software running
our fully automatic pallet conveyor systems.
The architecture is three-tier; host (not our system), service with
GUI (com uppwards and downwards plus supporting the operators of the
plant) and PLC nearest the el-mech.

We decided to go for python since we always could fallback on ansi c
in case of performance issues.

We have today no regretted this!
We have extended the architecure since with handhelds and they are
programmed with java due to lack of proper python possibilities (at
the time).
We have further programmed code generatord for the PLC code.
and so on.. :o)

Sure, c++ could have been used but not at the effort(lessness) we now
experience.

Mu 2 cents//Maria
--
http://mail.python.org/mailman/listinfo/python-list

Re: any issues with long running python apps?

[Maria R]

I can second the stated opinion that Python per se is stable enough.
We deliver production systems running 24/7 with uptimes counted in
several months
and from what I can see, compared to the OP's app, ours is vastly more
complex.

The only Python-related issue we have encountered so far, wrt to
stability, is how
timers are working. Extensive creation of timer threads have locked up
after some
indeterminable time. We found that the issue was probably related to
some update in
Windows at the time.
We do not know whether this issue is resolved (we encountered it back
in Python 1.4)
and we rewrote our code to use timers differently.

I also second that partitioning the solution in working (server) parts
and GUI (client)
parts is important.

I do not second the generally outspoken distrust in Windows. Indeed, I
would prefer *nix/*nux
but in our case, stability concerns is not one of the issues behind
that.

We use threading to a certain extent (in addition to partioning into
processes). One approach we have,
and have shown very useful to gain stability, is to use Exception
handling carefully and extensively.
We catch *every* exception, report and counteract but do not allow the
process/thread to die.
This is not a trival approach, by no means, but when one know the app
sufficiently, it can be applied
with good results.

Just my 2 c
//Maria

-- 
http://mail.python.org/mailman/listinfo/python-list