Hoobs

NJ501: Details needed on the SktSetOption instruction

7 posts in this topic

In doing a bunch of socket programming on the NJ501-1300, I have found what appears to possibly be an error/omission in all the manuals related to this controller.  There is an instruction mentioned in numerous places, the "SktSetOption" instruction, but nowhere am I able to find details on it.  What options can be manipulated?  How is that done?  Is there status information returned?  While it is mentioned in several places, it is *not* in the NJ Instruction Reference manual, unless there has been a recent update to this manual that I have been unable to track down.

Does anybody know where the usage details for this instruction may be found?

Thanks!
--Al

Share this post


Link to post
Share on other sites
Just now, Hoobs said:

In doing a bunch of socket programming on the NJ501-1300, I have found what appears to possibly be an error/omission in all the manuals related to this controller.  There is an instruction mentioned in numerous places, the "SktSetOption" instruction, but nowhere am I able to find details on it.  What options can be manipulated?  How is that done?  Is there status information returned?  While it is mentioned in several places, it is *not* in the NJ Instruction Reference manual, unless there has been a recent update to this manual that I have been unable to track down.

Does anybody know where the usage details for this instruction may be found?

Thanks!
--Al

The instruction does exist and the details also provided, but :
Capture.thumb.JPG.dac7932543f120aa484c21
 

So now the question is, what controller are you using, what version, and what version of Sysmac Studio are you using

Edited by innoaloe

Share this post


Link to post
Share on other sites

I'm using an NJ501-1300, version 1.12.  Sysmac Studio is 1.20.1.0.

--Al

Share this post


Link to post
Share on other sites
Just now, Hoobs said:

I'm using an NJ501-1300, version 1.12.  Sysmac Studio is 1.20.1.0.

--Al

Well... this instruction is used along with a TCP Socket object (you need to have either SktTCPConnect or SktTCPAccept first which outputs a Socket)

There isn't much to do with the SktSetOption FB. You only had one possible enumerator for OptionType which is _eSKT_OPTION_TYPE#_TCP_NODELAY

Then the OptionParam need to be a BOOL variable whose value is either TRUE / FALSE.

 

I'm not sure what is the NoDelay function is used for. All I can think of is that Send/Receive action needs to be done instantly if the Param is set to true

Share this post


Link to post
Share on other sites

OK, thanks.  Interesting that's the only option.  I assume the TCP_NODELAY enumerator maps to the RFP-defined option setting down in the tcp/ip stack with the same name, if so then I know what it does.

Thanks for making sure I know about sockets in general.  Yes, I've done network programming for about 30 years, and I'm familiar with sockets...   :)      There's an interesting problem I'm having currently, in which it appears that SktClose() is not closing a socket that I successfully created with SktTCPAccept.  I've confirmed with a port scanner that the port is indeed still open on the NJ, even though in Sysmac Studio I'm looking at the power trace running right through the SktClose() instruction and it is kicking off no errors.  Thus, the socket logic all works great the first time through, but then the socket isn't closed and SktTCPAccept can't open another on the same port when a second request comes through.  Any thoughts on that are greatly appreciated as well!

Thanks!
--Al

Share this post


Link to post
Share on other sites
26 minutes ago, Hoobs said:

There's an interesting problem I'm having currently, in which it appears that SktClose() is not closing a socket that I successfully created with SktTCPAccept.  I've confirmed with a port scanner that the port is indeed still open on the NJ, even though in Sysmac Studio I'm looking at the power trace running right through the SktClose() instruction and it is kicking off no errors.  Thus, the socket logic all works great the first time through, but then the socket isn't closed and SktTCPAccept can't open another on the same port when a second request comes through.  Any thoughts on that are greatly appreciated as well!

Well 30 years is 10 times my work life these far :D... Cheers to you

I've been doing TCP related stuffs with Omron PLC and I must say Closing a Socket is one of their weakness. Old models like CP1L-EM requires us to wait like 2 minutes before we can re-open a same socket. Why that happens I don't know... should be some hardware design issues.

However the same cannot be said for NJ I'd say. In my experience it does the job properly.
As stated by by SktTCPAccept manual, a same Local Port number can be used for different instance of Sockets. What needs to be make sure of is that the Socket Handle is really closed.

I'd say you can try to crosscheck the current status of the Socket Handle using the following FB and enumerators :
And just a though, but AFAIK for a TCP Server, we don't really need to close the socket should only a single Client IP is connecting right?

Capture.JPG.e987d0770a53dcd023a375c03245

Share this post


Link to post
Share on other sites
6 hours ago, innoaloe said:

I'd say you can try to crosscheck the current status of the Socket Handle using the following FB and enumerators :
And just a though, but AFAIK for a TCP Server, we don't really need to close the socket should only a single Client IP is connecting right?

Thanks for the FB hints...  I had started down that path to see what would happen, it's good to know that is one possible "accepted" path to handle this.

Re: single connection to be accepted as a "server"...   In my case I've built a simple proxy server that will sit between an httpd and the PLC.  I intend to have the PLC always listening on somewhere between 8 and 16 ports all the time with SktTCPAccept, and the proxy will handle making round-robin requests across these ports.  Until a request on a port completes (correctly or with an error) the proxy will not attempt another connection on that port.  So, yes, you are correct, we don't technically need to close the socket.  However, the httpd is sessionless in nature, so I need to think through the architectural considerations of where to switch from a sessionless processing model to one that involves a persistant session.  I'm not sure yet where I'll come down on that.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now