Messages

21

Works in progress / Re: 3 Axis Simple Screen setup 1.0 (Also good for TouchScreens)

« on: April 28, 2007, 05:29:04 PM »

Jason, greetings

Good to hear that things are going well.

I sent you a PM a fortnight or so ago asking if you could let me have the .FLA for a complete screen set so I can catch up on the refinements you have made to the structure of the library and your Actionscript strategies for setting DROs etc.

I really do need to make a test Flash screen set :=)

John Prentice

22

Works in progress / Re: Plain vanilla lathe screen. Operates by keyboard or mouse.

« on: September 12, 2006, 03:42:37 AM »

I will send an alert to Art, so he can consider if it is possible for us to make hotkeys to select different DROs.
I think your idea would be good if we could get rid of the mouse alltogether.

This functionality exists with the original Screen Designer - any DRO can have a Hotkey defined. So far as I know the capability was dropped in Screen4. You can however use a mixture of designers so just set the hotkeys in SD and do any fancy skins etc in Screen4

John Prentice

23

Finished Plugins for Download / Re: Rules and disclaimers for posting plugins

« on: June 02, 2006, 04:53:50 AM »

Can I suggest some additional points? Well I'm going to anyway :=)

(a) Using a Zip or Rar archive allows you to include the DLL and any supporting files as an package. A self-extracting archive is ideal.

(b) As plugins are all go in the same folder, try to use a different DLL file name from that used for existing plugins. Otherwise, on unzipping, the user may wipe out what s/he already has.

I have setup a trial page in the customization wiki to list the names used and provide links to the place for the download this is at:

http://www.machsupport.com/MachCustomizeWiki/index.php?title=Index_of_Plugins_that_have_been_developed

(c) You will get many more users prepared to try/test your Plugin if you provide some release notes describing what it is intended to do and the configuration required

John Prentice

24

Mach SDK plugin questions and answers. / Re: Some general questions on Plugins

« on: May 31, 2006, 01:46:00 PM »

John,

Yes. But do keep in mind that worst case there could be 100 instances of a given plug in... (Not especially likely from where I'm sitting right now, but...<G>)

Point being that as long as Mach gives each instance (of a plugin type) a unique identifier as it is turned on (since Art says we can do that on the fly during application run time); then the rest is do-able by and IMO properly belonging to the plugin writer.

If the above shows that I've misunderstood where you're getting your two uniquly identified identical binary files PlgDev1.DLL and PlgDev2.DLL; help me understand?

Yes we could have 100 instances of Foo.DLL and the method would be poor in this case - which is why I said the workaround was for 2 or 3 instances.

The issue is to pursuade Mach3 that it needs to instantiate a given number of instances. Having separate DLL files fools it. My original Idea was:

"I feel that it would be good to allow the user to give a name to an entry in the Plugins list (e.g. ToolChanger, Pendant). I.E. the list for a Profile would be manually setup by adding (installing?) DLLs in the Plugins folder rather than just being automatically built from all the DLLs in the folder. That way multiple instances could be defined and run. This name would be accessible to the DLL code and could then be inserted part of the XML tag names defined when the plugin config code is run so making them unique."

i.e. the user by setting up and naming 3 entries gets 3 copies of the DLL running. Art however saw problems with this so the different named DLL is a proof (or of course disproof!)of concept workaround.

John Prentice

p.s. GetModuleFileName(0 does allow the DLL to discover its name - so that looks good.
 

25

Mach SDK plugin questions and answers. / Re: Some general questions on Plugins

« on: May 31, 2006, 12:42:26 PM »

Art,

Why not use a combination of "well-behaved" plug-ins which take care of the conflicts between each other, AND an enumeration "read-in" OF the plug-ins at M3/4 initialisation?

You're already creating a list of available plug-ins. Then we get to instantiate from that list as we wish. How about giving each one a superscript/subscript type ident as you read it into usage?

Following this line of thought but without any new features needed in Mach3, my next experiment is to try to see what would happen if I have the same binary code in two files, say,  PlgDev1.DLL and PlgDev2.DLL. Provided I can get Windows to tell me the name of the DLL file then I can make up a unique name string for return by SetProName and Mach will not know or worry that they are the same beast. The DLL will of course know which instance it is and do suitable things with its interpretation of pin numbers, shared buffer addresses and XML profile key names.

Of it works the only cost is not sharing the actual code but it is IMO much better for two or three potential devices (e.g. handwheels or Modbus devices) than having to have a two level config architecture to support multiple devices in one piece of code.

John Prentice

26

Mach SDK plugin questions and answers. / Some (more) general questions on Plugins

« on: May 31, 2006, 03:48:26 AM »

Art

Many thanks for your replies. I even think I see how the Helper Thread gives control over the running rate now!

A few more overnight questions. I will continue the letter sequence in case people want to chip in with cross references:

(f) I wonder about the techniques for multiple instances of a given plugin. Suppose we have some of those nice USB-connected Jog/Shuttle dials that the video editing guys use. The simplest plugin would support one peripheral giving, say, jog and step control of one axis. If I want two dials then I could probably copy and rename the DLL and configure it for another axis. But the plugin name would of course be the same in the list and worse the XML tags for the configuration would be the same and get totally confused.

It would be possible to design the code to support multiple devices but this seems like hard work when what is needed is multiple instances of one driver. The issue is not hypothetical as it arises when one wants to support two ModBus devices of the same type at one time (e.g. two ModIOs or DL5s)

I feel that it would be good to allow the user to give a name to an entry in the Plugins list (e.g. ToolChanger, Pendant). I.E. the list for a Profile would be manually setup by adding (installing?) DLLs in the Plugins folder rather than just being automatically built from all the DLLs in the folder. That way multiple instances could be defined and run. This name would be accessible to the DLL code and could then be inserted part of the XML tag names defined when the plugin config code is run so making them unique.

(g) Might there be a problem with dead-wood in Profiles caused by having once run a given plugin? If so the proposal in (f) would certainly makre it worse as the user could keep inventing new "names"!

(h) The extended port numbering thing is not only related to motion controllers. If one has two similar Modbus devices then a given terminal will naturally be a given Mach pin number. To distinguish them it is, I think, easiest to be able to nominate the port that each device belongs to. There are other solutions, of course but another level of mapping from multiple devices onto different pins of port 0 feels wrong.

(j) I wonder if you or anyone else reading has any good ideas on distribution and installation procedures for the users? By definition most plugins will not be part of the Mach release. A self extracting archive would be fine for the momenent and anyone with an "InstallSheld" type system could provide a rekease package. Are there any other good ways?

Enough for now, thanks

John Prentice

27

Mach SDK plugin questions and answers. / Some general questions on Plugins

« on: May 30, 2006, 11:51:56 AM »

Hi Art,

I am sure I will learn much more by a bit more reading and trying some code. Art does give us license to "play" - and doubtless break a toy or two. A few question relevant to where I am now are:

(a) Would it be possible for the InitControl () routine to be called later in Mach initialization? It feels to me that I might have to have a "first time" flag and test it in Update () so I can be sure all the Mach variables are set up before I do my initialization which is unfortunate. Config is not generally a useful place to initialize things as it will generally not be called in a working system.

(b) Art says that the plugin is not a separate thread when called during Init - Is the plugin always called in the main Mach3 thread (I am not sure I know what I mean by that). What are the "critical section/mutex" issues accessing data in Mach if one gives up control by (e.g.) using a modal dialog box? In particular the engine is obviously a separate thread so one needs to be very careful with its data (e.g. the TrajBuffer).

(c) Is there any mechanism by which a plugin can see the press on an OEM button (e.g. what could a button or macro script do to raise a flag)?

(d) By multiple threading you can "run at speeds up to 100 times per second". Does this implay one can get a latency in a plugin of 10mS? If so can you eaplain a bit further please?

(e) Very usefully it looks as though a G100 (or any other pulser) will be able to co-exist with parallel ports - not to split axes between I/O routes of course but to allow encoders or switches on the parallel. This means that the Mach "port" number range will need extending and Config in plugins needs to be able to say which "port" the plugin "drives" At present Modbus is hardwired to Port 0 and G100 to Port 1 (was 0). The config is needed because of arbitrary combinations of plugins. It may be a bit hard to explain to the user too!

Probably more later :=)

John Prentice

28

Mach SDK plugin questions and answers. / Re: New SDK plugin development forum.

« on: May 30, 2006, 07:39:08 AM »

Art

No problem - happy to do the easy bits.

John Prentice

And the e-mail Notification system does work - although the info. on my Profile screen seems unreliable

29

Mach SDK plugin questions and answers. / Re: New SDK plugin development forum.

« on: May 30, 2006, 07:07:01 AM »

Apologies that the wiki is rather crude in its formatting rules.

I have been able to make Art's excellent info. on structures and variables a bit easier to follow by some editing. If you had problems please re-visit it at:

http://www.machsupport.com/MachCustomizeWiki/index.php?title=SDK_Variables

If anyone wants to post their own code the "rules" that work are:

(a) One or more spaces (not tab) at start of a line gives a TeleType font in a box.
(b) Avoid blank lines (i.e. new paragraphs in wiki markup) inside a collection of lines (e.g. a struct) as these will start a new box.

If you dummy edit the page linked above this should make sense!

On a different tack I am hoping that by setting up Notifications in my Profile I can keep track of any postings in this thread. It really is too easy reading Yahoo! with PGOffline ;=)

John Prentice

30

Works in progress / Re: New Screen released ( Beta 1)

« on: April 04, 2006, 04:38:16 AM »

Benny

Thanks for all your efforts on this - both the screnset and the development, with Art, of the infrastructure to make them possible.

A few early thoughts:

(a) The hotspots on a bitmap architecture feels very responsive compared with multiple bitmap buttons and the automatic animation feels very natural - wondeful given that no work is needed by the "designer" for pressed/unpressed renderings etc.

(b) I have tried Arial and the 7-segment font. Arial works fine and is vastly more legible IMO. Users should not be put off feeling they must use the 7-segment version.

(c) Now a problem: I really need to have the S DRO on screen and ideally some buttons to increment/decrement it (My screen buttons multiply and divide by 1.2 to give geometric speed steps). In the current release format the screens are, for all practical purposes, uneditable. One of my principal requirements is to be able to optimise a screenset to the hardware it is controlling (e.g. one needs spindle pulley controls on a multi-geared head, a Tool Change request LED if manual tool change, different coolant options etc.) A universal screen is so crowded as to be useless.

Have you considered a "release package" including the "object" format files? My personal view would be that as there is no proper standard format and as RealDraw Pro is such a good and reasonably priced piece of software that .RDW files would be the best format.

(d) Finally some details:

I feel that + buttons should be on the right and - on the left when in a pair (e.g. for jogging)

It feels wrong that the page selection buttons are so much bigger than the Cycle Start etc. The latter are too small (in height) for safe use with my fingers on a 17" touch screen.

The screens need to display their "revision data".

It is useful (to me at least) to have the profile name displayed.

I frequently refer to the Modes line.

If you are planning work on Offsets then I have found it useful to display the arithmetic involved (see attachment). The screen shot may be too elaborate as G52/G92 may be little used.

Best wishes

John Prentice