How do I know when the file is done?

[team08]

I am writing my own interface over the SB3.EXE and am passing files to the command line using the Process object in c#. I am triggering an event when the process is complete, but it seems like this happens very quickly (before the file is really done). So the DOS command prompt returns immediately (meaning everything is sent to SB3 immediately and SB3 does not hold the process open until done). Is there any way to get feedback from when SB3 is done with the file? I am sure I can do something creative with writing to a file when done, but want to know if there is anything more native. Thanks!

[dana_swift]

SB3 reads the entire file very quickly then generates a series of segments. What you are seeing is the time to read the file and for SB3 to close it.

If you get any info on the feedback question I would love to know, but Im not aware of any provisions for external automation.

I have thought about figuring out how the USB communcations works and just reading the file (I have an SB3 parser in C#) then sending out the machine protocol. The problem is each time SB changes the firmware the protocol probably changes also, so it becomes a cat and mouse game of catch up. But then the bot could run from linux, or any other operating system for that matter.

Keep us posted on the feedback issue-

D

[fmihm]

This isn't related to getting feedack from SB3 and is probably way off the track, but if some DOS program operation is happening too fast to be correct, maybe there was an DOS error, but the DOS error message couldn't be seen.

To configure a DOS program so that it doesn't close on exit (and hide the error message):

In Windows Explorer, right-click on the DOS program name (or its PIF).
Select "Properties."
Under the Program tab, uncheck "Close on Exit."
If "Apply" isn't grayed-out, click it.
Exit Properties by clicking "OK."

If you do this, you should now be able to see any DOS error messages.

When you're done debugging, you can reset Properties so the program will again close automatically on exit, and you won't have to manually close it every time.

HTH.

[team08]

So my solution thus far is indeed to write to a dummy "status" file at the beginning of the part file. So before I launch the SB3.EXE process, I place in a file:

STATUS=WAIT

Then in the SBP file, the first thing the shopbot program does is write to that file:

STATUS=BUSY

Then my program launches a background thread that spins on that file, looking at the status. At the end of the SBP file, the shopbot program writes:

STATUS=DONE

At this point, the background thread reports that shopbot is done cutting. A little hack, but works very well. I will let you know if I find anything else!

[dana_swift]

Greg, thats an interesting solution, however not all SB3 files exit at the end of the file text. This is especially true if any logic is added to the file to handle special situations, if that is not a concern then just adding the end of file hack is just plain clever.

Its a shame that it takes such a kludge, but I like the external semaphore you have created as a signaling mechanism to tell when the SB3 file is really done interpreting.

Good work!

D

[team08]

So I have my first problem with this solution. It is an issue of both programs accessing the file at the same time (typical issue with this sort of solution). I am sure I can fix it on my code's side by testing if another process has the file open, but I cannot do anything on the shopbot side as far as I know. Any other ideas?

[dana_swift]

I have requested (through tech support) shopbot add UDP communications to the SB3 control program just for such purposes. Probably I am the only person who has ever asked for it, so they don't see enough demand to bother with it. Perhaps you can put in the same request and we can get a high speed communications channel for peripherals that doesn't have the lockout problems.

It would also be handy for telling the SB3 program the current state of the vacuum pumps, temperature, or other things that the sbp files could use in making better parts on the bot.

What follows is my wishful thinking:

For asynchronous input from the external world, I can imagine having an additional "ON" statement that would look like:

ON UDP_PORT 4567 FROM_IP 123.12.34.56 GOSUB HANDLE_IT

The "from" specifies where the packet must come from and prevents some kid from manipulating the shopbot in a class over a schools internet. (Just thinking ahead!)

an alternative might be:

ON UDP_PORT 4567 FROM_ANY GOSUB HANDLE_IT

FROM_ANY is good for when you are operating over a closed network and you can guarantee any packets destined to that port came from an authorized source.

The subroutine to handle the message might look like:

HANDLE_IT
OPEN UDP_PORT 4567 FOR INPUT AS #1
... read the contents of the message
... do something appropriate with the information
CLOSE #1
RETURN

Likewise to send a UDP message:
OPEN UDP_PORT 123.45.67.89:4567 FOR OUTPUT AS #2
... Write a message to the machine:port specified
CLOSE #2

I also suggest allowing UDP broadcasting by:
OPEN UDP_PORT 4567 FOR OUTPUT AS #2
... send a message to the world
CLOSE #2

All outgoing UDP messages should have a time to live of 1. So they don't get passes through internet-routers.

I would suggest not using TCP for this, as TCP can hang waiting for a message to finish transmitting. Using UDP guarantees the program will never hang.

Also UDP is GUARANTEED delivery within a subnet, this is a required part of the Ethernet protocol. The only time UDP becomes unreliable is when the message has to traverse an internet-router. The router and Time-to-live parameter determine whether the message gets passed along or not.

End of wishful thinking-

D

[richards]

Dana,

I can't find anything saying that UDP is guaranteed within a subnet. Where can I find that information? What I found was this: "Packets may be lost or corrupted in Ethernet due to interference and noise, since Ethernet does not retransmit corrupted packets."

[gittel]

Greg,
Morris Dovey had an interesting idea which could solve your problem with file handle locking. SB3 allows you to specify an external editor for the "FE" (file edit) command by using the "UN" command to specify your editor. The trick is that you can specify any program to be the "editor", so effectively SB3 can launch any arbitrary program in response to the FE command. Let's call your program which starts SB3 "launcher", and let's call the program which SB3 runs when it encounters the FE command, "signaller". Write a thread in "launcher" which makes a server socket which listens on a port (like 9999). When it receives a "done" message on that port, it is done. The "signaller" program just writes "done" to that port. I've written "launcher" and "signaller" in Java, and they work to send the signals. The SB Part file which specifies the signaller program is:
m2 20, 20
un "C:\projects\shopbot\shopbotsignaller\shopbotsigna ller.exe"
fe done

Write me if you want the programs.
Mike

[dana_swift]

Mike, it is because it is carried on an Ethernet packet. Ethernet guarantees either complete transmission, or notification of failure within a subnet. Its when an IP packet gets to a router that UDP can be legally dropped.

The specific answer to your question is the IEEE 802.3 series of specifications. When a packet is carried by Ethernet the "ethertype" field of the datagram specifies the payload type. When the payload is InternetProtocol there is no provision in 803.3 to allow selective unreliability (as UDP is just one case of sub-payload under internet-protocol). Collision detection with re-transmission is how ethernet works, so ALL packets get the same level of reliability. No packet is guaranteed to go through on the first try, but some number of tries is attempted then an error is generated. That applies to ALL packet types TCP, UDP, etc.

A TCP datagram is mostly identical to UDP with extensions which make the packet LONGER increasing the probability of a collision on any given packet and in addition TCP requires something like 6 packets to transmit a single character, UDP only requires one.

To get a good instinctive feel on how reliable UDP is even beyond subnets, remember that the domain name service is based on UDP (port 53). It is very rare that the name resolver does not get a complete transaction the first query. In fact it is so reliable and requires no handshake, so it is often one of the faster parts of a network communication sequence. (Ideal for machine tool control messages!)

Ethernet does not have a mechanism to guarantee reception, and that is where TCP has an advantage, however if the receiver is on the same sub-net and running, the chances of missing any packet are almost zero, but it is technically possible that a packet will encounter noise and get lost.

Hope that helps

D

[richards]

Dana,

Thanks for the reply. I guess that the misunderstanding was the use of the word, "guarantee" vs "low probability". To me, if a protocol guarantees reception, there has to be a feed-back mechanism in place to "guarantee" that the reception took place and that the reception took place without error. To me, that requires that the sender expects a response within a certain period of time, that the response has to have some kind of verification, and that the sender will keep sending the packet until it receives a verifiable certification from the receiver. To my knowledge, those requirements are beyond the protocol used with UDP. What I understand is that the UDP packet is sent and that the sender assumes that that receiver has received the packet. Granted, that may be reliable on a subnet, but it certainly isn't fail-safe, nor is it guaranteed.

I've had to write packet handlers using ethernet, and the method that I use is to send a packet, wait a pre-determined amount of time for a verification, and then repeat the cycle for that packet, with a different ID, until a verification has been received. Most packets make the trip successfully on the first try; however, data, if it is important, has to be verified at both ends, so I don't use UDP for important data, not because it isn't a good system, but because I can't prove that the receiver received the data without error.

[dana_swift]

The word guaranteed is misleading in the case of TCP. If you pull the plug half way through a TCP stream how can delivery be guaranteed? It cannot, the failure "should" be detected, and that is all. I have experienced TCP failures too.

With that same use of the word "guaranteed" meaning if the packet gets interrupted and cannot be transmitted you will learn of the error, UDP is just as good within a subnet, with the caveat that if the listener is not listening, UDP does not provide a mechanism to find out.

In the case of the SB3 program finding out the current Vacuum pressure, all the vacuum gage needs to do is periodically send out the data as a UDP packet. If the vacuum pump is not running, no packets get sent, if the SB3 program is not running nobody is listening. The communication would behave rationally.

And ALL packets sent when both the vacuum pump was running and the SB3 program was running can be expected to be received correctly. The communication is rational, and "reliable".

It sounds like our backgrounds and network experience are very similar. Unlike yourself, I use UDP for messaging where the data stream can be turned off at either end without consequence. In the other case TCP is the clear choice.

On a subnet, I am not concerned with "lost" UDP datagrams. It is necessary to test to see if the UDP send routine returned an error, in which case the packet must be re-sent. There is no way to know the listener was listening, but if they were, they got the message.

To satisfy yourself that ethernet "noise" is or is not a problem, set up a UDP test between two computers on a subnet. Make the UDP datagram be a 32 bit integer count incrementing by one with each packet. Dropped packets are easy to detect. Resend any packets that encounter "transmission errors". If you send a billion packets, how many will be lost? Care to make an estimate before running the experiment?

I fully grant you cannot PROVE that a packet will be received in the legal sense without a user-implimented protocol on top of UDP. Serial data is just as "unproven". But it can be "reasonable certainty".

Certainly good enough for the proposal I made..

D

[Gary Campbell]

Guys...
I dont want you "scary smart" guys to think I belong in this thread, but I would like to throw a little gas on this fire!

When the new boards come out, along with the additional inputs and outputs, maybe the addition in the SB3 software to add selectable "handles"? to the inputs such as "causes the machine to lift and pause" or "returns the following message" would be great for vacuum monitors, prox switches mounted on hold down clamps or other special purpose items that always seem to either get in the way of the bit or cause other problems.

Good news is SB is working on the new gen boards and they have more I/O, bad news is I will have to have one of you help me implement the ideas!

Gary

[richards]

Dana,

You've got some good ideas. In the past, I've read ideas about various forms of networking when the writer wasn't experienced with the possible problems inherent in an ethernet connection. You've got ideas and you've got experience to implement those ideas.

One of the things that I normally do on the "client" computer is to write a timer routine that times out if the "client" computer doesn't receive a message in a predetermined length of time. It works kind of like an E-stop switch. The E-stop switch is normally closed, so if the wiring breaks or the switch is opened, the E-stop "stop" signal is received. In the same manner, the client expects to receive an "I'm here" message as often as necessary to ensure that the process is being properly monitored. Whenever a messages is received, the timer restarts. If the timer "times out" before a message arrives, then either the connection is broken or something else that needs attention has happened.

Providing "hooks" for UDP would greatly enhance the usefulness of SB3 software. If the granularity were fine enough to allow critical process monitoring without interfering with stepper pulses, those hooks would change the face of CNC routing forever.

[dana_swift]

Gary! Glad to see you reading all this! If UDP support over gets implemented I will guarantee you will be one of the people that use 100% of its capacity to improve your installation. Your use of readily available technologies to vastly improve your system leave me in awe. You would love UDP messaging if it were available for all the "temporary suspend operations" ideas you have in mind. I see even more applications.

The next generation controllers will get a lot of attention from all of us, what makes shopbots so powerful is their flexibility. Adding UDP would just open up a whole new range of capabilities.

Mike.. I did not write the SB3 or controller software, so what I say here is just my opinion, and could be quite wrong.

The SB3 software doesnt appear to create stepper pulses, it creates sequences of move commands and feeds them via serial or USB to the controller. The controller generates the stepper pulses.

The controller makes the motion happen by sending step and direction commands to as many as 5 drivers, it is a dedicated uP and interpolates up to 5 simultaneous coordinated axis moves from one point to another. When it arrives at the new point it executes the next move command in the sequence from the serial queue.

If communication takes a brief break, the motion stops at the point of the last command. When communication resumes the motion continues with the command sequence.

The only real-time communications that appear to be happening is the detection of the prox switches and the "switch" of the zzero plate/or probe. Those loops are closed through the SB3 program, communications latency here is an issue, but time-stamped messages have been used to overcome these problems elsewhere. Perhaps shopbot uses that now, I have no way to know.

What I would most like to see UDP available for is to allow tool change commands, spindle communications, etc. Who knows what inventive folks like Gary will come up with for it?

D

[ted]

Hi Guys,

In answer to an early question above, you are not the first 2 people to ask for some sort of public event flag. You are number 2 and number 3.

But your point is well taken. We'll move that one up the priority list, now. Hopefully you will all have it to play with by Gary's Camp.

In addition to the editor kludge noted above, you can also create 'Virtual Tools' and add them to the VirtualTool.ini list, which will then let you call a simple program from within an .SBP file with a [T?] Command.

For that matter, we'd love for others to contribute VT's and would be happy to maintain some sort of public download site for them. We have not yet created a management system for handling user-installed vs ShopBot-installed VT's because we've had few people create them, but we will be happy to do it when the need arises. The CustomCut and Vitrual Tool systems provide simple ways to provide all ShopBotters with new capabilities that creative people develop.

The next beta, that we will hopefully post in a day or two, includes a new toolbar interface that allows adding your own buttons. These can call CC's or VT's or any other ShopBot command in a convenient way.

Ted Hall, ShopBot Tools

[team08]

Can I pretend to be the 4th to ask?

Any idea when we might see something like this put in the control software... or is it in there already?

[Gary Campbell]

Greg...
Look at the latest Beta Software...Down the page a bit on the ShopBot Control software page. There are some very good things coming. The more we all use it... the faster it come to be a reality.
Gary

[Ryan Patterson]

Look at the Beta page. http://www.shopbottools.com/beta_notes.htm . The Beta version of SB3 now uses the registry to interact with outside programs. All the information is in the Programming hand book found in Help Programming and developer Resources. You can download an example (VB .Net) of how to use the registry with link below. This example should work with the free version of .Net Express.
http://www.microsoft.com/express/download/

www.shopbottools.com/files/readreg.zip (http://www.shopbottools.com/files/readreg.zip)
The compiled exe is in the root of ReadReg
Source code/project is ReadSbReg\ReadSbReg.vbproj

[dana_swift]

Using the registry for a dynamic communications media seems like a pretty strange idea to me. Who knows tho.. it may be better than things like networks, but I will try it out. Just downloaded the Beta..

If it is such a good idea, why not communicate with the shopbot itself using the registry?

Just musing out-loud.

D

[Ryan Patterson]

Dana,
The beta will allow you to communicate with SB3 through the registry. The .Net example shows how it is done. You can pass any ShopBot command through the registry.

[dana_swift]

Ryan- I understand the paradigm, it seems like a very awkward method of communication, although it could do the job. I read the documentation, and clearly understand it.

This communications method does not seem equal to the quality of the rest of the shopbot.

Kind of like a dog walking on its hind legs, its interesting that it can be done, but no dog chooses it for normal operations..

I still advocate adding UDP to do the same functions, it is real-time has built-in event handling under any .NET platform (and other programming languages through callback functions) therefore much more appropriate to the task, in addition the programs do not need to be on the same computer. UDP would be a very effective method of communicating with the shopbot or anything else, better than "pseudo RS232" over USB.

What I see that I really like is the SetUsrValue and GetUsrValue functions from within the SBP file. That uses the registry as a database, which is its function in the system, and is a great idea for allowing programs to set values that change rarely so the SBP file can get them. Much cleaner than communication through standard files due to the API calls for registry access.

In any case I am glad there is any method at all for inter-process communication, thats an improvement. I will add support for it in my C# shopbot control library, probably tomorrow, then I will use it a while. The jury is out till then.

However it works, I will have it at Gary Campbells camp in Florida for anybody to check out.

D

[dana_swift]

Greg- Here is the C# interface to the status flags:

using System;
using System.Text;
using Microsoft.Win32;

public class ShopbotRuntimeStatus

[team08]

Wow, great! Thanks for sharing Dana. I will have to get to work to try this out. I too find it a bit funny to be messing with registry keys... but at least it is a solution!

[dana_swift]

Greg- It is not a great solution to say the least.. I hope SB uses it as a learning experience to come up with a better approach.

However, you are welcome to see how to use the communication method from C#.

D

[joe]

Jeeeeeeeseeeeeee

[richards]

The Shopbot has eight output signals. Surely one could be dedicated as a status signal. Most PCs have a parallel port that is sitting idle. The Shopbot controller could send a signal to one of the input lines on the parallel port to signal the status of the cut.

The master program that initiated the call to the Shopbot sbp file could call the sbp file and then wait until the sbp file sent a "busy" signal. Then the master program could periodically check the signal until it saw a "finished" state.

It's not very exotic, but it would work. It's the same principle that you'll find on most alarm panels. When a red light turns on or a bell starts to ring, the operator knows that he has to put his book down and do something.

[josh_g]

Ryan- You're right! The beta will allow you to communicate with SB3 through the registry. All you have to do is take a look at the .Net example, and you can then see how it is done. Any Shopbot command will pass through the registry.

Thanks for helping everyone here!

Josh
Wisconsin Auctions
http://wisconsin-auctions.com

[jseiler]

You can do a lot of interesting stuff with an mbed microcontroller, including implementing the watchdog timer (or timers).

www.mbed.org (http://www.mbed.org)

[team08]

Just a quick reply to this OLD thread... but in case anyone is interested in how I finally solved this issue, I did it very kludgily (is that a word?). Anyways, I took my initial idea of writing to a file at the end of a shopbot file, but on the c# side, I am just looking at the file size. This way, I don't have to open the file on the c# side, and can just test the size until something is written to the file!