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

Hello John:

  a) >>Would it be possible for the InitControl () routine to be called later in Mach initialization?
Good point. During writing of the PlugIn I used the prior-to-config for a reason, that was simply that if something crashes , the computer will not have to have drivertest.exe run in order to clear a stuck driver. (As you know you have less than 4 minutes or so till BSOD if the application crashes..).
However, I have solved that in another way, so I will have it next version, being initialised later on...

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
   
   Mach4View is actually the primary thread of the program. In each loop of its message pump, it calls, TrajectoryPlanner, and all the windows, one by one, with the call Update(). The PlugIn is simply one of those windows. Things like ModBus, MacroPumps, and serial controls exist in their own threads. They steal time when all else is idle, or between messages of the MachView program loop. Th ePlugIn, has the exact same priority as a Window, DRO, or LED, it is called exactly as often. It is possibel though, for a plugin to start a thread (or multiple threads, and each can have a timer which can be run up to 10ms or so in granularity, it woudl then call its own timer routine as often as it likes. Examples of this will show up in near future plugins. A great deal of complexity can be added this way without affecting badly the timing of th emain Mach3 loop.


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)?

   At the moment, only by use of semaphores. While the plugin is a once per loop called routine, it has no message passing capability added to it, however, I can add a message script call such as CallPlug() which shoudl be able to send a message to the plugin which woudl trigger a routine to be called. The problem woudl be to make a message number that is identifiable by the plugin and not mixed with another...solvable though..

(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!

  In theory, quite true. I had arbitraily designated port zero as ModBus, and port 1,2 as printer. The G100 turns off the printer port in MachIV, but it will be possibel to have it run in parallel, though i woudlnt try it till the end of G100 plugin functionallity. Too much possability for interferance in timing relationships. The printer lowers a machine to about 1/2 of its cpu time, so best to turn it off. My plan is to designate port 1 or 2 as any motion device. This is an arbitray decision, but based on theoretical limits in time. Experimentation may prove me wrong at the end, but I think Ill leave that as a limitation at the moment.
 I think time is required to learn exactly what the limitations are, and then to add fucntionallity if the hardware permits.

Thanks, (Good questions..)

Art

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

Hi John:

  Your doing too much reading, your questions are getting harder.

(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.

>> This is very complex to do. Not only because M3 woudl have to recognise each plugin, but because each plugin woudl have to recognise another. Its my feeling that a plugin , properly designed, should take into account other devices of its type. This is likely to be a failing in some of the earlier plugins. For example, my joystick plugin looks for any JoyStick and uses the first it finds. It is not settable to the stick #. Properly done, it shoudl "tag" that stick as used, and it should then ignore it so another plugin could grab the next stick. (If multiple sticks are desired. ) and then xml tags should reflect the device being used. All very hard to do.  A further problem is that when a plugin calls into MAch3, its very hard for MAch to tell WHO is calling, it just knows its a plugin. There is no enumeration device to show exactly whos on the phone, this makes it very difficult to make an easy interface to multiple objects. I suspect I can add support for this type of thing as I learn more on the shortcomings involved, but I think I'll do it as the next few Plugs are made, just in case a better solution pops up as I go. Even I have not played in this area enough to be considered an expert.  But in the interim, I really recommend a plgin be the master of its device type. It is my hope by having most of them as open source, that some integration can aoocur of features for various types of devices, but this will always be an area of concern I think. Of course, for th eavergae user, his interest will be in using 1-5 plugins, each representing a particular device, someone for example, with multiple ModIO's is likely to be somethign of a configuration expert and not as concerned as he will already have learned the shortcomings of that type of system.

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)

>> ModBus is, I think a special consideration. I am designing it be be an all in one solution, where only one instance is used. I suspect this "first of the real" plugins will show us the problems we're likely to see. We'll have to discuss this more as I find ways around the problems about to hit me on this..

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.

>> Probably a good idea. Ill see what I can do as I go. Mach3 for its part simply allows a plugin to be turned on or off at the moment, but turning off one instance of a plugin, will turn them all off. Multiple instances does seem a lot of redundant code, but may be the way to go.

(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"!

>>Thats one of the concerns I have. At the moment, the XML tags the plugin name as on or off. If a plugin is deleted, then that particular deadwood is left, but I doubt it will eveer add up to much at the moment, there can be only one deadwood per plugin type right now..

(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.

>> For ModBus it isnt so bad, I think ModBus needs to be one PlugIn per device type, and Im designing it to know what type is what. I have created 64 different modbus data areas, each name tagged to a type of device. Though undoubtedly problems will arise. I dont think I can anticipate them as yet. This is one of those "LEarn as you go" type of things. Its good to plan, but in this area, Ive found planning tends to go out the window as you solve more intricate types of problems found, thus making prethought solutions redundant.

(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?

>> This one does concern me a bit. My thought is to write a small system registerable ocx. (very small ). Its job will be to recognise a plugin, downloaded plugins will have an extention like *.M3P and will download to your desktop or other area. Wehn you double click it, the OCX will recognise the *.M3P extension, and know to copy this to the Mach3 plugins folder and remove it from the desktop or place it was downloaded to while renaming it to *.dll. This type of Auto-Plugin facility woudl I think, make installation fo plugins a no-brainer.


 Hope this clears up some items, likely it raises others..

Regards,
Art

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?

read in. If already in use, increment instance ident value for the plug in (by type).

So the first modio plug in is modio(1), and the next one mach sees is modio(2) . Now mach knows they are different but it still expects THEM to "play fair" with each other...

Seems a fair division of the labor of keeping things "clean". Plug in writers have to do their part (like you describe in the joystick availablilty example), and you provide the means for multiple instatiations to be properly recognised by mach... 

Plug-in writers could use the instance ident to HELP their plugins play fair...

Ballendo

>> This is very complex to do. Not only because M3 woudl have to recognise each plugin, but because each plugin woudl have to recognise another. Its my feeling that a plugin , properly designed, should take into account other devices of its type. This is likely to be a failing in some of the earlier plugins. For example, my joystick plugin looks for any JoyStick and uses the first it finds. It is not settable to the stick #. Properly done, it shoudl "tag" that stick as used, and it should then ignore it so another plugin could grab the next stick. (If multiple sticks are desired. ) and then xml tags should reflect the device being used. All very hard to do.  A further problem is that when a plugin calls into MAch3, its very hard for MAch to tell WHO is calling, it just knows its a plugin. There is no enumeration device to show exactly whos on the phone, this makes it very difficult to make an easy interface to multiple objects. I suspect I can add support for this type of thing as I learn more on the shortcomings involved, but I think I'll do it as the next few Plugs are made, just in case a better solution pops up as I go. Even I have not played in this area enough to be considered an expert.  But in the interim, I really recommend a plgin be the master of its device type. It is my hope by having most of them as open source, that some integration can aoocur of features for various types of devices, but this will always be an area of concern I think. Of course, for th eavergae user, his interest will be in using 1-5 plugins, each representing a particular device, someone for example, with multiple ModIO's is likely to be somethign of a configuration expert and not as concerned as he will already have learned the shortcomings of that type of system.

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

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?

Ballendo

Quote from: ballendo on May 31, 2006, 11:52:07 AM

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

Good points. But since MAch doesnt care in the end how many instantiations of a p[llugin exist, I lke Johns idea of just looking to the file name and using that in the PlugIn name. That woudl make Mach3 see them as all different in the list. It woudl make it easy. Only the plug in cares about the number of instinces, so it can use that information to determine cause and effect.
  I will give this soem thought though, it does seem I coudl do that without great trouble/.. Again, too early to say. Ill focus on getting a MoiodIO plugin done in the meantime..its underway. I get the feeling each one I write will point out to me more that I need to do and add. It'll likely grow in the next several weeks to the point where things are handled better.

Thanks
Art
 

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.
 

John:

  Just remember that if you use such a scheme, to also use the writing and reading fromthe XML using the new name. Otherwise they will all have the same setup data stored in the Mach3 XML file. I do like thi sthough, it owuld allow for the filename to reflect the stored setup data and such.. Its actually a good idea, I lean heavily toward getmodulename() as a setup name as well as a plugin name...

Art