Sharing data and resources between threads

[xdmattz]

Hi Tom,

I'm in the middle of rebuilding an old VMC and am retrofitting it with a KFLOP and a custom board that is based on your Kanalog and Konnect boards. The tool changer on this VMC communicates with the KFLOP board through an RS422 interface on the serial port. I have a simple serial command protocol running and can easily send commands from the main thread (1) and have a serial monitor function that is constantly looking at the serial receive buffer and processes messages. I had originally tried to run the port at 115200 baud but it was missing received data some times. Slowed it down to 57600 baud and it seems to be working fine. I was wondering what the size of the transmit and receive buffers are for the serial port. It appears that the transmit buffer is larger than the receive buffer because when I tried to time the code that sends the messages by setting and clearing a test bit. The message is only 5 bytes and the KFLOP only take 5us to send it so there must be some buffering going on.

What I was thinking of doing was having the the actual tool change be managed in another thread, initiated from an M06 code for example or another user button. But now I'm worried I might have a resource allocation issue.

I'm pretty sure that it is not realistic to try and call functions in tread 1 from another thread. I thought I saw something about this once, but I can't remember where.

The persist variables are the obvious choice but it looks like it might get a bit complicated. It would be nice to be able to send a serial message from any thread, and I'm assuming that once the serial port is initialized in thread 1 that any other thread that writes to it will just stick its message into the serial transmit buffer and not collide in the middle of another threads transmit message, especially if it occurs right after a WaitNextTimeSlice(), but I don't know how much room there is in it and I wouldn't want to overrun the buffer.

I would like to use the serial port to communicate with more than just the tool changer. I want to query the state of the buttons on my MPG via the same serial port, not the encoder position, just the axis and rate buttons. And I'd like to have the flexibility to add some other yet undreamed of peripheral to this serial port too.

As far as serial receive goes, I think there is no way around using the persist variables since I can't predict when a receive character is coming in.

And finally if more than one thread is running, will this slow down my ability to process the serial port? A byte at 57600 baud takes about 174us to send and the single thread time I believe is 180us - so right on the threshold. There was something in the ModBus example code about this I think.

Thank for making such a cool product!

Dan Matthews

[TomKerekes]

Hi Dan,

I had originally tried to run the port at 115200 baud but it was missing received data some times. Slowed it down to 57600 baud and it seems to be working fine. I was wondering what the size of the transmit and receive buffers are for the serial port. It appears that the transmit buffer is larger than the receive buffer because when I tried to time the code that sends the messages by setting and clearing a test bit. The message is only 5 bytes and the KFLOP only take 5us to send it so there must be some buffering going on.

KFLOP's UART has a 3 character buffer in hardware and a 1000 character buffer in software. See these definitions in KMotionDef.h

Code: Select all

void InitRS232(int baud);
void EnableRS232Cmds(int baud);

extern char * volatile pRS232RecIn;  // Buffered Receive Pointer Head
extern char *pRS232RecOut;           // Buffered Receive Pointer Tail
extern char *pRS232TxIn;             // Buffered Transmit Pointer Head
extern char * volatile pRS232TxOut;  // Buffered Transmit Pointer Tail
extern int volatile DoRS232Cmds;     // Enables/disables KFLOP Command processor to/from RS232
#define RS232BUFSZ 1000
extern char RS232RecBuf[RS232BUFSZ];
extern char RS232TxBuf[RS232BUFSZ];

char RS232_GetChar(void);   // Get Internally Buffered (1000 chars) RS232 received Data 
void RS232_PutChar(char c); // Put Internally Buffered (1000 chars) RS232 transmit Data

Every 90us Servo Sample KFLOP may read/write 1 character from the UART hardware. This works out to 111111 baud. So 115200 baud is just over the limit and will not work reliably except for receiving only several characters at a time. Sending will work reliably at any rate except there may be timing gaps between transmitted characters.

What I was thinking of doing was having the the actual tool change be managed in another thread, initiated from an M06 code for example or another user button. But now I'm worried I might have a resource allocation issue.

I'm pretty sure that it is not realistic to try and call functions in tread 1 from another thread. I thought I saw something about this once, but I can't remember where.

The persist variables are the obvious choice but it looks like it might get a bit complicated. It would be nice to be able to send a serial message from any thread, and I'm assuming that once the serial port is initialized in thread 1 that any other thread that writes to it will just stick its message into the serial transmit buffer and not collide in the middle of another threads transmit message, especially if it occurs right after a WaitNextTimeSlice(), but I don't know how much room there is in it and I wouldn't want to overrun the buffer.

I would like to use the serial port to communicate with more than just the tool changer. I want to query the state of the buttons on my MPG via the same serial port, not the encoder position, just the axis and rate buttons. And I'd like to have the flexibility to add some other yet undreamed of peripheral to this serial port too.

As far as serial receive goes, I think there is no way around using the persist variables since I can't predict when a receive character is coming in.

I think most all of those options are possible. But I'd recommend having Thread #1 handle the Serial port and have other Threads request Thread #1 to do something for it. An approach I often use is to have one Thread set a non-zero positive command code request into a variable, then have the other thread detect the code, perform the action, then set the variable to zero when completed or negative on error.

And finally if more than one thread is running, will this slow down my ability to process the serial port? A byte at 57600 baud takes about 174us to send and the single thread time I believe is 180us - so right on the threshold. There was something in the ModBus example code about this I think.

As described above KFLOP services the UART in the 90us Interrupt. So it can reliably handle less than 111111 baud regardless of the number of active Threads.

Thank for making such a cool product!

Thank you for your patience using it!

[xdmattz]

Thanks for the quick reply Tom.

KFLOP's UART has a 3 character buffer in hardware and a 1000 character buffer in software. See these definitions in KMotionDef.h

Yep... there it is right at the bottom of KMotionDef.h!

So I wrote a simple program and loaded it into threads 2 through 7, and put my serial handler in thread 1. I have a test board connected which is running my tool changer micro controller code, so it responds to the proper commands and it had no problems at 57600, even with all the threads running. So no more worries about that.

I think I'll give your suggestion of setting a command bit in a persist variable then monitor it in thread 1 Ia try. I going to have to implement something like that anyway for the receiver. I just like the fact that when I immediately send a transmit message the processor is done in 5us, not the next time the other thread rolls around. - I've got to stop measuring everything in nano seconds... I'm sure that latency is not going to be a problem.

The thing that originally drew me to getting a KFLOP for my first milling machine was that I was running Mach3 through some chinese breakout board and trying to use a wireless MPG which was functional, but then I went over to a friend's house who had just got a used Haas and his MPG was so smooth and responsive that I knew I had to do something different. That and you actually all the PID loop information on your web-site.

I mentioned that I'm running a custom interface board based on your Kanalog and Konnect boards. When I first got the new VMC (old machine, new to me) I got a Kanalog board from you and started looking at what it would take to interface it to this new machine. The Kanalog board just didn't have enough inputs, and I needed some power conversion, and I wanted to use the original motor drive and encoder connector and I wanted plugin Phoenix connects etc. My interface was looking so complicated that I figured it would be cleaner if I put the Kanalog circuitry on the interface board. I did all the logic in an FPGA and was able to include an instance of a Konnect board too so I had plenty of I/O. And I ended up with a PCB that fit the old mounting holes in the cabinet. I'd be willing to share that design if you like, and approve, since the Kanalog and Konnect are your original work.

I'd post a picture of it but I can't figure out how to attach it!

[xdmattz]

OK, I read the forum help.

Here is a picture of the board from KiCAD


and here is one of it installed in the machine

[TomKerekes]

Hi Dan,

We have no issue with you sharing it as long as it is clear that we are not directly supporting it.

I suppose you reverse engineered the Kanalog logic?

Somehow the images didn't show up. To add images you can select Attachements - Add Files - then Place in-line.