Re: Jedicut and Arduino over USB

61
OK, I can say, that if the inverse box is checked the direction bit of the corresponding motor will be sent inverted to the microcontroller. At the moment there is no need to modify the dll.
Manfreds explantions of setting only the step pins to low and not the direction pins at the same time may be the solution. But due to the fact that we can free assign the pins to step and direction, the microcontroller code is not able to know which are the step pins. So we need to make a fixed assignement of step and direction pins in the jedicut configuration and the adaption to different machines may be done only by wire the microcontroller pins to the stepper board.
If all agree I would make a proposal of the fixed assignment and change the arduino code to reflect this assignement. I will then change the step mechanism to only pulse the step pin.:)

Martin

Re: Jedicut and Arduino over USB

62
Hi,
here is what I propose to use. I selected the pins in a way, that Clock and Direction pins resides on their own port. With this it is easier to write the pulse commands.
If we set the communication settings fixed to:
ParPortAssignment.jpg ParPortAssignment.jpg Vu 4592 fois 17.35 Kio
then the following wire schema must be followed:

[pre]
Function Number in jedicut configuration Arduino Pin e.g. Lethmate MDLCNC board
(fixed !!) SubD25 pin

EngineX1 Clock 2 D8 -- wire to --> 2
EngineX2 Clock 3 D9 -- wire to --> 6
EngineY1 Clock 4 D10 -- wire to --> 4
EngineY2 Clock 5 D11 -- wire to --> 8
EngineX1 Direction 6 D4 -- wire to --> 3
EngineX2 Direction 7 D5 -- wire to --> 7
EngineY1 Direction 8 D6 -- wire to --> 5
EngineY2 Direction 9 D7 -- wire to --> 9
[/pre]

Additionally I propose using pin 3 for PWM generation (the last free PWM pin) and arduino pin2 for switching e.g. the heating relays. Pin 12 I left unchanged for turning all motors on/off.

[pre]
All Engines On/Off - D12 -- wire to --> 1
Heating On/off - D2 -- wire to --> 14
Heating PWM - D3 -- wire to --> -
[/pre]

I updated the arduino code in the repository to reflect this situation. The code is now optimised concerning the step pulse generation, which avoids Problems like Vincents.

Martin

Re: Jedicut and Arduino over USB

64
Jerome,
I apologize for the unclear posting. It is a result of the discussion between Manfred and Vincent. Vincent had problems with motor direction and the timing of the clock pulse generated by the arduino. Manfred pointed up that there may be a problem with the time behaviour of the logical levels of the step and direction pins.
The background is the following: The logical level of the direction pin should be valid when the rising edge of the clock pulse happens and should be valid till the falling edge of the clock pulse. In the arduino code I set the direction and the clock pin levels with the same command (at the same time) and to generate the falling edge of the clock pulse I set all pins (including the direction pins) to zero, again with one command (at the same time). I have done it this way, because the microcontroller doesn't know which pins are clock and which pins are direction.
This seems to work with the letmathe mdlcnc board, but not with the mm2001. The mm2001 and other boards may need the logical level timing in the correct order. To solve this problem the arduino needs to know which pins are the clock pins to operate them independently of the direction pins and to generate the correct time sequence of the direction and clock levels. Unfortunately we can't (at the moment) transfer the jedicut pin configuration to the microcontroller and if the configuration of jedicut will be changed the arduino code need to be changed too.
To overcome this problem my idea was to hold the configuration within jedicut fixed, so the code for the microcontroller can be optimised for this configuration and only the wires between the arduino and the stepper board needs to be adapted (what needs to be done anyway). If you can set the clock and direction values to fixed values in the jedicut configuration when the USBSerial.dll is selected, then there is no other way to interface to the board as by making the correct wiring. This may save a lot of discussions and uncertainties in configuring.

Martin

Re: Jedicut and Arduino over USB

65
Hello,

According to me, the arduino code mus'nt itself clear or set bits, if the plug-in don't send them.
For easier updates, the plug-in must respect the "Emettrebit()" function like all others plug-ins :
-First it send the direction bits
-delay
-Second it send the rotation bits and hold the directions bits
delay
-And so it send the rotation bits to '0' and hold the directions bits.
delay

i think that if we want the Arduino works with many CNC board, all must be generate by the plug-in.

Re: Jedicut and Arduino over USB

66
Jerome,

I am sorry, but I think you did not understand my original intention. The origin idea of using a microcontroller was to avoid the restriction of using a parallel port by using USB. The second and very important thing was to let the microcontroller do the timing which it can do more accurate and without delays in comparisson with a PC, where delays are inevitable due to the multitasking operating system.
And to be as performant as possible another goal was to send as less data as possible over the serial interface. Additionally the wire heating can be made with PWM by the arduino, which I added in the last version.
The combination of the USBSerial.dll and the arduino affords this requirements.

The target of my last postings was to make it as easy as possible for everyone to use this solution. And I tried to reduce the necessary brain power to only think about how to connect the arduino to the specific stepper board.

Martin

Re: Jedicut and Arduino over USB

70
Hi,
theoretically it would be possible to send the pin configuration to the arduino. I think it needs to be done every time the serial port to the arduino will be opened. New commands need to be defined and jedicut needs to tell the USBSerial plugin the pin assignment. The arduino code must be written very flexible to handle all possible settings.
I am not sure if its worth, because the flexibility is already given by the wiring which needs to be done anyway.
I propose to let the pin configuration fixed (as explained in my Proposal) and if somebody has special needs which can not be covered, we can think about an extended solution.

Martin
`); }); })(jQuery, window, document, phpbb);