Messages

91

Mach4 General Discussion / Re: Making a connection through rs232 in Mach4

« on: November 25, 2019, 08:59:51 PM »

Happy to help!

Looking great so far. Can you post a screenshot of your windows device manager showing COM4?

Also what version of Mach 4 are you using?

ALSO, I forgot. Can you post the entire LUA error message if you haven't fixed that yet?

Mike

92

Mach4 General Discussion / Re: Making a connection through rs232 in Mach4

« on: November 25, 2019, 08:12:39 PM »

OK. Lets see here. You're missing part of your error code so I'll need to do some guessing. When LUA gives you the stack traceback errors they are a roadmap to how your code failed. Try to read and understand them as they are very valuable once you learn them. The "attempt to call a nil value" usually means you forgot to define or assign a value to something. All undefined variables have the value of nil and you can even assign nil to a variable if you would like. For example the code:

Code: [Select]

print(string)
Would create the "attempt to call a nil value" error since string doesn't exist. However, the code:

Code: [Select]

string = "Hello World"
print(string)
Would run perfectly fine.

I have recently been helping another Mach 4 user with their serial code. You might find this thread useful: https://www.machsupport.com/forum/index.php?topic=42084.0


First guess is that you did not assign a global value to "port_name" up at the top. This is the string value of the name of the COM port that windows assigns. When in doubt, open Windows->Control Panel->Device Manager to see the name of the COM port. Make sure you typed the name exactly.

Second guess is that you typed the name correctly but the port doesn't exist or couldn't be opened. I like to use a terminal emulator called PuTTY to test my serial communications. Make sure you can open a port and communicate through the terminal before you bother trying with Mach 4.

Third guess, once the port is open, it has the name "p" based on the example code above. All the methods in the serial library should be called using the name "p". For example:

Code: [Select]

p:close()
p:flush()
p:read()
p:write()
Only the function call to open the port should use "port_name".

If you post the entirety of your stack traceback then we can troubleshoot further. Please make sure to compile your code in ZeroBrane studio before trying to run it in Mach 4.

Mike

93

Mach4 General Discussion / Re: Axis as a Spindle using Jog? (or Serial??)

« on: November 23, 2019, 12:52:55 PM »

Simon,

Happy to help!

but the bit I'd missed was to close then flush the buffer and using two instances for Tx & Rx

Not entirely sure what you're referring to here. Ideally you keep the serial port open the entire time you are using Mach. I'm pretty sure Windows will automatically close the port when Mach 4 closes, but I opted to close it in the screen unload script anyways.

Without the flush, mine would send intermittently.  I'm guessing that when you create the instance, the buffer pointer has some random value - then depending on the string you send it, the buffer overruns?

As far as I know, the serial buffer is only used for data received on the open port (the buffer will not fill when the port is closed). Since writing data happens immediately, there is no need to buffer it. Without a buffer, you would need to get incredibly lucky to have your program looking for incoming data at the exact moment it arrived. Instead Windows captures and saves this data asynchronously from your code in the buffer.

Whenever the port is open, you should be able to write out the port, and it should happen immediately.

The buffer flush is not explicitly necessary, but I use it to make sure there isn't any junk in the buffer that I'd need to sort through to find the data packet I wanted. Even then, the serial code will handle a buffer full of junk characters as it looks for specific start and end characters and verifies the data with a checksum check.

This is only my second outing with Lua (first was an ESP8266) though I've coded in C++ & C# for a long time - so it's just getting my head round the different syntax & environment.

I was in the same boat as you 6 months to a year ago. I had just a bit of C++ experience and no idea what LUA was. The learning curve is a bit painful, but I really feel comfortable with the language now.

I'm also intending to use Ultra3000 drives on a Denford Cyclone F using Fanuc Red Cap motors.  I've had one spinning with pulse & direction though the motor needs a bit of tuning.  I'd not yet tried talking to the drives using Serial.

Wow! I'd love to hear how you got that working. It was my understanding that the Fanuc motors used pulsecoders with a proprietary serial interface that most drives couldn't understand.

In my setup, the serial data is just "bonus" stuff and my CNC would still work fine without it. I am using serial to configure the drives to my standard settings when Mach 4 loads, get the spindle load in real time, pull absolute position data into Mach 4 for homing, and hopefully soon - rigid tapping.

If you are interested, I would be happy to share my sister module to the serial one posted above that has all the functions to talk with the Ultra 3000.

If that fails, an Ultra3000 30A ought to be sufficient to drive it.  Then talking to the drive to implement the spindle as an Axis would be useful.  My intention is to add live tooling - for which this is rather important!

Sounds like a sweet setup! Would love to see it. Here to help with anything I can.

94

Mach4 General Discussion / Re: Servo Spindle Question

« on: November 22, 2019, 09:52:43 PM »

Craig,

I have observed the progression of your posts over the year, or so, time that you have been using Mach4 and your knowledge has
increased vastly and in certain areas far exceeds my own.

Coming from you this means a lot. I appreciate it. I have a long way to go but I am having a blast.

Will update this thread a bit later once I start some testing of the code.

Mike

95

Mach4 General Discussion / Re: Servo Spindle Question

« on: November 22, 2019, 03:26:41 PM »

I have a "Start-Up script" which sets everything to my default values and configures my servo drive parameters over serial when Mach loads. I will make sure to include a command to set the motor to OB1 every time Mach loads. I think this would get me around the issue?

I wish I had your depth of knowledge on Mach 4. I am working hard to get there, but there is a lot to learn.

96

Mach4 General Discussion / Re: Servo Spindle Question

« on: November 22, 2019, 02:53:46 PM »

That's brilliant! Thanks.

I guess I will have to home the spindle whenever I switch to the C axis since I won't know where it is at that time. I'm starting to think about getting rigid tapping working on this machine.

I will have the spindle assigned to OB1 at startup and only switch to C axis when needed.

Do I need to do a profile save or anything silly to get the changes to apply after I call that mc.mcAxisMapMotor()?

For example the simple scheme I have sketched out would
require that the servo be step/direction in both modes with the same steps per rev in each mode. That data is stored in the ESS
and cannot, to my knowledge, be changed on the fly. I would suspect that the ESS would need to be power cycled to pick up
the fresh data.

Good news is that I am already using the spindle in step/dir mode. I would have no need to change this or the steps per rev.

You've got to absolutely love modern AC servos!

They are absolutely the coolest engineering marvel in my book

Thanks for the help, will likely follow up with more questions down the road.

97

Mach4 General Discussion / Servo Spindle Question

« on: November 22, 2019, 02:13:08 PM »

My CNC has a Step/Dir servo spindle motor which holds position of the spindle very tightly. I currently have it set up as OB1 and control it with M03/M04/M05.

I would like, in a small set of use cases, to be able to command incremental positions of this spindle (position control). Say use a G code command C1.0000 to command 1 revolution forward of the spindle.

What is the "proper" way to configure a spindle in Mach 4 such that I can use both M03/M04/M05 *and* C#.####?

Are there any gotchas when doing this?

98

Mach4 General Discussion / Re: S curve

« on: November 22, 2019, 12:43:21 PM »

Given that information, I think you really do have a strong case for needing S curve path planning.  When we design industrial servo motion systems at work, S curve is employed when motion smoothness and vibration suppression are of concern. Given the exact same move, the S curve will be slower than a trapezoidal, so by itself it does not give you faster motion. However you stated you are limiting the speed to keep vibration in check, which is exactly when S curve profiles would help.

Separately, you may be experiencing higher vibration due to mechanical differences between your equipment and your European competitors. S curve path planning certainly could help, but it is not a replacement for stiffer mechanics.

Unfortunately, I don't feel like I have the expertise to provide advice on modifying you Gcode/Post Processor.

99

Mach4 General Discussion / Re: Axis as a Spindle using Jog? (or Serial??)

« on: November 21, 2019, 10:02:13 PM »

Some additional tips...

When I am developing new code, I often place some buttons on screen which execute a small chunk of code when clicked. To do this, I go into the screen editor and add a new tab to the Operations Tabs. Inside this tab I place a new button, give it text, and paste my chunk of code into the "Clicked Script" area. This would be a great place to develop your code to write "Hello World".

If the serial cable gets disconnected, the open port command will fail and "p" will have a value of nil. If you later try to use a serial function like p:write(), you will get a LUA error which will stop script execution in Mach 4. It is necessary to check if "p" actually exists before trying to use any serial commands.

It isn't always good enough to send a command and assume all the transmissions went correctly. When possible, try to read your changes back from the drive to verify they were applied.

100

Mach4 General Discussion / Re: Axis as a Spindle using Jog? (or Serial??)

« on: November 21, 2019, 09:33:42 PM »

Simon,

Here are some of the key parts of scripting serial communications. I have attached my Mach 4 module (titled mcServo) which I created to communicate with my AB Ultra 3000 servo drives. If you do want to use this module, just be aware that the functions are tailored for my particular communications needs (including checksum calculation and verification, timing requirements, and Master/Slave communication). You will need to learn how the serial library works and use my scripts as an example to build what you need.

First off, you need to add the following header to wherever you are writing your scripts. This gets the current Mach 4 instance, includes the use of the LUA serial library, and defines a variable with the name of whatever COM port you would like to use. The io.stderr[/code] line was included in some example code I found, however I don't know if it is necessary or what its function is.

Code: [Select]

local inst = mc.mcGetInstance()

rs232 = require("luars232")
port_name = "COM1"
local out = io.stderr
Next you need to open the Serial Port and set the communication parameters. In this example I open COM1 at 38400 Baud and 8N1. You will find I do handle exceptions in the real serial module (attached), however they have been removed for clarity here.

Code: [Select]

e, p = rs232.open(port_name)
-- set port settings
assert(p:set_baud_rate(rs232.RS232_BAUD_38400) == rs232.RS232_ERR_NOERROR)
assert(p:set_data_bits(rs232.RS232_DATA_8) == rs232.RS232_ERR_NOERROR)
assert(p:set_parity(rs232.RS232_PARITY_NONE) == rs232.RS232_ERR_NOERROR)
assert(p:set_stop_bits(rs232.RS232_STOP_1) == rs232.RS232_ERR_NOERROR)
assert(p:set_flow_control(rs232.RS232_FLOW_OFF)  == rs232.RS232_ERR_NOERROR)
From now on, your open port will be named "p" and the methods you call will begin with "p:". For example if we wish to close the port, we use the following, where "e" is a returned error code.

Code: [Select]

e = p:close()
If we wish to flush the serial buffer, we can use either of the following lines of code. Obviously using the method :flush is simpler, however reading the entire contents of the buffer (4096 bytes, 5ms timeout) is equally effective.

Code: [Select]

e = p:flush()

e = p:read(4096, 5)
Now comes the good stuff. If we wish to write "Hello World" out of the port, we use the following. Note the use of standard string escape characters, in this case \r is carriage return. If you had a laptop with PuTTy open and connected to the serial network, you should see "Hello World" appear on the screen. len_written is an optional function return which gives you the length of the written string

Code: [Select]

e, len_written = p:write("Hello World\r", 5)
To read data on the port, we use the following. In this example we would be reading 10 characters (bytes) which included non-printed characters like carriage returns and applying a 5ms timeout. Again, "e" is an exception code (hopefully zero), "data_read" is the string of characters read from the port (this is what we want), and "size" is the length of the received string.

Code: [Select]

e, data_read, size = p:read(10, 5)
If you are writing out on the port and expecting a response back, it is a good idea to flush the buffer immediately before writing.

Please ask questions if you have them.

Mike