M-functions and remarks
Posted by
Jan
on 1999-12-03 05:08:45 UTC
To Fred and the rest,
1. I noticed some problems with the M-functions. I'm using M7-M8-M9 to fulfil some tasks. The program code is like this:
N1 G21 F500
N2 G0 X0 Y0 Z0
N3 M7
N4 Z5
N5 M9
N6 M0
...
The problem hereby is that M9 will not be executed (sometimes) unless the program is restarted.
Z5 is only used to give a time interval between between the two M-functions
Also I noticed that this problem exist more when M7 is active then with M8.
2. As I know to make a I/O parport-extension with 256 in or out's, can you or somebody else point to me what I need to add to the source to call all the addresses for the outputs with M-codes and to read all the inputs.
3. Fred, if we all on this list send you a birthday-card can we convince you for the need of two additional functions in EMC.
The first is that we can nest programs. This allows us to have a private library of functions and when milling multiple pieces we don't have to put all the code in one file but just have a driving program to go to the right place and execute the called program. For us (at home) this is quit useful as we're working with digitised data and mill 50 copy's at once. One copy is about 2 Mega big and we're working with ftp to retrieve the milling data from the server!
A further way of thinking is when programs can work with 'parameters' , read variables who can be placed for every value in a program, it could look like:
G0 X = P1 Y= P2 F=P3
then our private library is even more friendly. By example; when a user needs to mill an ellipse he can make a program for every size he needs. But when working with parameters he can just fill in the value for A and B to have any size wanted. When all this can be combined with some loop-functions you end up with an interface where only the imagination of the user is the limitation of what he get out in time and performance of his machine. I like that.
Second, O.k. I will send you a cake as well, is when we could run, pause and resume a program by means of data trough the par-port or the STG-board. I get these functions now by having my key's R,P and S of my keyboard directly connected to a PLC. But you have to admit that this is not the most proper and secure way to achieve an automatic toolchange.
3. On this side of the water we work metric. This can be achieved by putting G21 in the program. This works fine for MDI and AUTO but when I want to give an axis a value by right-clicking on it I got strange results. My ini-file is put on metric.
4. For your information; working with KDE is not the windowmanager of choice for EMC. Losing focus when selecting items, out of the menu, with a mouse is the most common problem. Starting EMC can give errors as well but running in simulation first and then switching back to normal execution can solve the error's ?
Does anyone have experience with Gnome or other more user-friendly wm's? Feel free to inform me, as I would like to abandon fvwm.
Hoping to recieve your date of birth,
Have a nice weekend,
Jan.
1. I noticed some problems with the M-functions. I'm using M7-M8-M9 to fulfil some tasks. The program code is like this:
N1 G21 F500
N2 G0 X0 Y0 Z0
N3 M7
N4 Z5
N5 M9
N6 M0
...
The problem hereby is that M9 will not be executed (sometimes) unless the program is restarted.
Z5 is only used to give a time interval between between the two M-functions
Also I noticed that this problem exist more when M7 is active then with M8.
2. As I know to make a I/O parport-extension with 256 in or out's, can you or somebody else point to me what I need to add to the source to call all the addresses for the outputs with M-codes and to read all the inputs.
3. Fred, if we all on this list send you a birthday-card can we convince you for the need of two additional functions in EMC.
The first is that we can nest programs. This allows us to have a private library of functions and when milling multiple pieces we don't have to put all the code in one file but just have a driving program to go to the right place and execute the called program. For us (at home) this is quit useful as we're working with digitised data and mill 50 copy's at once. One copy is about 2 Mega big and we're working with ftp to retrieve the milling data from the server!
A further way of thinking is when programs can work with 'parameters' , read variables who can be placed for every value in a program, it could look like:
G0 X = P1 Y= P2 F=P3
then our private library is even more friendly. By example; when a user needs to mill an ellipse he can make a program for every size he needs. But when working with parameters he can just fill in the value for A and B to have any size wanted. When all this can be combined with some loop-functions you end up with an interface where only the imagination of the user is the limitation of what he get out in time and performance of his machine. I like that.
Second, O.k. I will send you a cake as well, is when we could run, pause and resume a program by means of data trough the par-port or the STG-board. I get these functions now by having my key's R,P and S of my keyboard directly connected to a PLC. But you have to admit that this is not the most proper and secure way to achieve an automatic toolchange.
3. On this side of the water we work metric. This can be achieved by putting G21 in the program. This works fine for MDI and AUTO but when I want to give an axis a value by right-clicking on it I got strange results. My ini-file is put on metric.
4. For your information; working with KDE is not the windowmanager of choice for EMC. Losing focus when selecting items, out of the menu, with a mouse is the most common problem. Starting EMC can give errors as well but running in simulation first and then switching back to normal execution can solve the error's ?
Does anyone have experience with Gnome or other more user-friendly wm's? Feel free to inform me, as I would like to abandon fvwm.
Hoping to recieve your date of birth,
Have a nice weekend,
Jan.
Discussion Thread
Jan
1999-12-03 05:08:45 UTC
M-functions and remarks
Ray Henry
1999-12-05 11:15:31 UTC
Re: M-functions and remarks