Messages

1621

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

« on: June 02, 2006, 11:16:51 PM »

Hi Junior:

   My thought was to make a system OCX that recognises a particular extension, if I were to name all plugins as *.M3P , then a system OCX could be registered to move any *.M3P file that is double clicked to the C:\Mach3\PlugIns folder. That way a PlugIn could just be download anywhere ont he desktop for example, and double clicking it woudl send it to its home. That may not work though as soem plugins may need support files.. Im not sure how to handle that yet. I think the G100 Plugin will teach me what I need to know about what we need.
 However, it will take me a couple weeks to make one up, so Id be happy to have one to do us for awhile. The Mach3 folder itself is probably a good place for it.

Thanks
Art

1622

General Mach Discussion / Re: Losing Position

« on: June 02, 2006, 11:11:33 PM »

Hi:
 The only condition I can think of where verify will lift and immediately drop again, is when the system senses that there was home ref done since turnon.
The Z lifts to prepare fo rthe move to home. If it then senses no legal home position has been set, then it will simply dop again. Is it possibel that the homing was not done in that session, perhaps the program was started up and zeroed to the work for a run, but hjoming to the switches was not done?


  I agree with the position being way to far off, .2 inches is way to far in anyones books. , but looking in the code, the only possability woudl seem to be that the homing was determined to be not sone prior to verify, or the home switches sensed as inactive.

  If in you rposition, Id run some tests to see if I could track it down. First, single axis tests.. 100 rep's of G0X10, G0x0 and makie sure it returns to zero. Repeat on each axis. Then I do 100 rep's of G12I10 with the tool zeroed in the center of the table. Does it come back to perfect zero?

 These tests usually help track this type of error down.  Let me know how you do.

  If the program senses it woudl be wrong to do a verify, you wont get the Z lift in preperation, so I think your in an OK condition when your trying to do it.

Thanks
Art

1623

Finished Plugins for Download / Re: Modified Joystick plugin by Junior

« on: June 02, 2006, 10:31:50 AM »

Hi :

  I have sent juniour a letter on the problem with the message box if the joystick isnt centered. (This was my error). Itll be fix it in the next verison..

Regards,
Art

1624

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

« on: May 31, 2006, 11:15:49 PM »

B:

 Im not suggesting they rename DLL's. A dll should be named by its inventor. All a user shoudl have to do is doubleclick it when it downloads and have it autoinstall. From there, it should never be necessary to delete one, it can be simply turned off if they dont want it. I dont think muliple instance DLLs will be a norm, a simple dll will do the job for 99% of things. But I think its too early to tell. By the time I get a ModIO , and a DL5/6 dll out in the next 2-3 weeks, then we'll start to see what the issues are if any..

  Its all too new to say as yet..

Art

1625

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

« on: May 31, 2006, 01:54:07 PM »

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
 

1626

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

« on: May 31, 2006, 01:44:33 PM »

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
 

1627

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

« on: May 31, 2006, 08:09:59 AM »

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

1628

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

« on: May 30, 2006, 09:19:10 PM »

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

1629

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

« on: May 30, 2006, 07:29:57 AM »

Hi John:

 So sorry to make you jump the hoops. , I added that last last night and figured Id edit it later for formatting. I have more to add very shortly on the other two classes..

Art

1630

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

« on: May 29, 2006, 10:46:14 PM »

Hi Guys:
 
  Post any specific questions here and Ill keep tabs on this thread for getting back to you. Also keep track of the customising Wiki, Ill be posting explainations of each of the main block variables , I just added the Engine variables tonight.
We'll be adding as much as possibel tot he PlugIn sections of the code to allow for more power. The first big project is to add the G100 as a PlugIn, undoubtedly more functions will be added to support the complex interface required by a G100, so by the time the G100 is switched to a Mach plugiin, th eplugin facility will have enough power to hook pretty much anything in.

Regards,
Art