Sieg KX1 & Mach3 won't come out of emergency reset

[Jess]

So, this is my understanding of the law as a layperson; I'm not a lawyer. When I've had trouble, mentioning 'The Sale of Goods Act' and 'Trading Standards' has usually helped, albeit we were talking about significantly less money. I'm also talking strictly as a consumer; if you bought it as a business - or with the appearance that you were a business - different rules apply.

Obviously, if do have trouble with Arc then you may want to speak to someone like Citizen's Advice etc.,

I have considered asking Arc to make it right. Like I say I've had the mill for a while but only really got down to putting it to use over the last few weeks. I was concerned that they'd use that somehow against me.

Certainly, it's easier when it's a recent purchase. There's a period of time where the seller is responsible for showing that the buyer broke it; and after that the onus moves to the buyer. However, given its just been sat on a bench, it seems fairly obvious that you didn't break it. Definitely get in contact ASAP to say that you're still having trouble.

That and they aren't the ones providing the support.

Your contract for a working mill is with Arc. They've just asked you to speak with their subcontractor for support. Even if the subcontractor messes up, liability - as far as you're concerned - remains with Arc. (Arc may be ab

I am covered under UK law for a year right? Worth considering I suppose...

UK law doesn't state a period here; just that to be of satisfactory quality, the goods must last for a reasonable amount of time. Reasonable depends on the goods; a reasonable life for a bio might be a few weeks whilst a washing machine might be 6 years. Seems a >£3000 CNC machine

If you don't like the computery bit as much as the making chips bit, look away now:

Have you read up on the error-checking and packet resending features of the Ethernet Protocol?

I'm well aware that Ethernet does error checking and it's fairly weak in terms of detecting errors. However, the problem a realtime environment specifically faces is the missing deadlines due to latency. You can resend data all you like, but it's no good knowing what you should have recieved after you needed it!

Some processes will be quite happy with the latency that Ethernet alone can provide of course, but as standard hardware and software can typically achieve that, they are outside of the realm of what's typically considered 'realtime'. Some problems only need accurate synchronisation, so you can work around Ethernet's unsuitability by using something like IEEE1588 for to create a common time reference and then queuing up commands. However, if you want to do, say, synchronized spindle and axis motion via a feedback loop, which you'd need to do something like rigid tapping on a mill, Ethernet simply isn't fast enough to do read the spindle speed and update the axis motion based on that speed. The workaround here, is that we move all the realtime stuff into a box that sits on the 'side' of the machine, outputing step-dir signals, telling things to move over CAN etc., based on, say, G-code-like commands - but Ethernet is no longer involved in the 'realtime' stuff.

The common thread is that Ethernet is unsuitable for realtime stuff: we either have to:

1. Formulate the problem so we can exempt Ethernet from realtime demands
2. Move the control part somewhere so it's not using Ethernet for realtime demands
3. Call it Ethernet for marketing reasons but exempt your solution from actually being Ethernet.

Where routers are involved information can travel several different routes and still be resolved at the destination, this is why the images which you view in your internet browser show so few errors.

That's nothing to do with Ethernet.

The appearance of (near) error-free, in-order, non-duplicated transmission in my web browser is a service provided by TCP - a couple of protocol layers up. It's done by numbering the packets and resending packets that are missing or have checksum errors (with TCP Ethernet's checksums are redundant) as well as dropping duplicated packets.

And routers don't even need to be involved either! Multiple routes can occur with any medium (including ethernet!) that allows for more than one path or the alteration of paths due to link failure.